Last week we noticed that some of our longer running batch processes were consuming much more memory than we had expected. We were able to narrow down the GC root to the observer collection in JdbcResourceLocalTransactionCoordinatorImpl

When a Session is created with a shared context it will add a TransactionObserver in order to track whether or not it needs to autoclose and also if it needs to execute any transaction level events from the ActionQueue. This all seems to be working as designed however there was a change made between Hibernate 4 and 5 where a piece of code that was removing the TransactionObserver on Session close.

From what I can tell there isn't an actual need to keep listening to the transaction once the session is closed, I don't believe you can do anything with the session after close and any transaction events are registered with the root Session's ActionQueue in the shared session context.

What is specifically happening in our case is that the we're spinning up shared sessions mainly to change load query influencers or perhaps to insert some audit type data that we don't want in the main session. This results in a SessionImpl instance being trapped in memory for every call that we make until the transaction is committed. I've created a simple test as a pull request against current state of master that demonstrates that after close the session remains in the observer list.