[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-3495) CollectionAction instances can consume considerable memory in large transactions unnecessarily

CollectionAction instances can consume considerable memory in large transactions unnecessarily ---------------------------------------------------------------------------------------------- Key: HHH-3495 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3495 Project: Hibernate Core Issue Type: Improvement Reporter: Tim Downey Attachments: CollectionActionPatch.zip Hi, We're doing some fairly heavy duty batch processing using Hibernate 3.3.1. In doing so, we're basically paging over large chunks of entities where we flush and clear the session around pages. We do not commit between pages. We may be processing hundreds of thousands of entities over pages of ten to twenty thousand each. We're clearing the session around pages in attempt to free up memory that is no longer necessary. We have found that subtypes of CollectionAction get added to a list of Executable in the ActionQueue when there are collection changes processed. These CollectionActions are held until transaction complete and are not released on flush or clear of the session. Furthermore, the CollectionAction instances hold references to those collections that have changed even after the entities have been evicted from the session. In our case, this was causing Hibernation to hold on to several hundred MB of RAM until transaction commit. I've supplied a small patch that doesn't require the CollectionAction to hang on to the entities themselves until the transaction boundary. We're showing considerably improvement in memory utilization as a result. I'm hoping that you consider this patch for inclusion in a future release. The change was basically to change the ActionQueue's list of Executables used in after transaction completion, to a separate type, AfterTransactionCompletionExecutable. This new type allows some decoupling in the other subclasses of Executable to hold references to fewer resources and save considerable memory when the transaction sizes are quite large. Regards, Tim