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

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 Assignee: Gail Badner 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.