[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-3028) Memory consumption when query cache is enabled

[Tim Downey (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=42646#action_42646 ] 

Tim Downey commented on HHH-3028:
---------------------------------

I was the one who opened the other issue with the patch.  I was actually looking at it this week since we're trying to update to the newest Hibernate and I agree that the issue seems to have been fixed.  The fix isn't the same as the patch I added in HHH-3495 as some things have changed in the cache SPI, but it seems to provide the same benefit.

I expect to be able to confirm this for sure some time in the next week or so when I run some regression tests of my app against our bulk data.  It will be apparent when I run against our bulk data since it will end up requiring more memory than I have. ;)

I'll comment again once I've verified things experimentally.

> Memory consumption when query cache is enabled
> ----------------------------------------------
>
>                 Key: HHH-3028
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028
>             Project: Hibernate Core
>          Issue Type: Bug
>          Components: caching (L2), core
>    Affects Versions: 3.2.5
>         Environment: Hibernate 3.2.5, Oracle 9i
>            Reporter: Markus Heiden
>
> As discussed in the hibernate-dev mailing list from 9.11.2007 to 12.11.2007 this bug describes a memory consumption issue which is located in ActionQueue/EntityAction.
> Some snippets from ActionQueue:
> private ArrayList executions;
> public void execute(Executable executable) {
>   final boolean lockQueryCache = session.getFactory().getSettings().isQueryCacheEnabled();
>     if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) {
>       executions.add( executable );
>     }
>   ...
> }
> This code leads to a kind of memory leak, because if the "executable" is added to "executions", the related entity which is referenced from the "executable" is prevented from being garbage collected until the transaction ends. So if one needs to insert large amounts of transient objects in one transaction, there is no chance to get rid of the inserted objects by flushing and evicting them, if e.g. the query cache is enabled.
> One solution to this problem might be to rework the above "if" condition to only add objects to "executions" if this is really needed. The problem is to determine when it is really needed.
> Some snippets from EntityAction (which implements Executable):
> private final Object instance;
> public final Serializable getId() {
>   if ( id instanceof DelayedPostInsertIdentifier ) {
>     return session.getPersistenceContext().getEntry( instance ).getId();
>   }
>   return id;
> }
> public final Object getInstance() {
>   return instance;
> }
> Another solution might be to set the reference to the related entity (field "instance" in EntityAction) to null after flushing. This does not prevent "executions" from being filled, but the related entities might be garbage collected and so the memory consumption is acceptable. The problem is that subclasses of EntityAction use the "instance" field for post transaction work.
> The are currently two workarounds to this problems:
> 1) To always disable the query cache
> 2) To use shorter transactions
> Workaround 1 is not really acceptable, because it prohibits the use of a very useful feature. 
> Workaround 2 is sometimes acceptable but not wanted in most cases, because it breaks transactional safety.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira