"Kevin.Conner(a)jboss.com" wrote : "mark.little(a)jboss.com" wrote : The current implementation assumes that the AtomicAction instance is around after termination for status, identification and in the event of heuristics potentially for management and recovery information (the log still exists on disk at that point and hence the AA instance can be used to access it). Changing it so that is no longer the case could have implications throughout the areas of the code. I'd prefer to see what is keeping hold of the TransactionImple reference and not releasing that, since it appears that is the root of the leak (assuming we're understanding the reported problem.) | No reference to the internal coordinator appears to exist outside of the transactionimpls and their associated transaction manager. | | The majority of the methods in the base transactionimpl classes assumes that this reference can be nulled, the only unsafe methods appear to be equals(jts) and hashCode (because their results can change) and also get_uid. The subordinate transactionimpls would also have to be change to check for a null coordinator. | I'm not happy to make such a change in code that has worked successfully for a long time unless it's strictly necessary: so far I'm not convinced it is. AtomicAction is exposed outside of the implementation allowing for recovery hooks with 3rd parties (see previous entry). Changing that behaviour can have significant knock on effects. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4028160#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...