]
Strong Liu resolved HHH-3495.
-----------------------------
Resolution: Duplicate
duplicated by HHH-3028
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, 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: