I have to process a large number of entities in a single transaction.
This is a typical batch of operations scenario. Following the recommendations found in the documentation, an abstract alogrithm is as follows:



This works nicely (and very efficently - thx Hibernate) until the Query Cache is enabled. This seems very suprising at first glance since there is no query involved in the above scenario (the createEntity() method creates a new object from static data).

I ran the test through a memory profiler and discovered that - although the Hibernate session is periodically cleared - it still holds a reference to every operations performed until now (and apparently until the transaction is committed or rolled back) - causing serious memory problems in the above scenario.

For those who know the codebase, these references are kept in the SessionImpl.actionQueue.executions array list.

This behavior is of course causing serious memory problems in the above scenario.

Hence my question:
I'm not questionning this behavior - but would like to find a way to avoid this problem in this particular scenario while still having the query cache enabled for the others.

(forgot to mention this is happening with Hibernate 3.1.2, 3.1.3 & 3.2-cr3 - didn't test the others)

Ten years later, but I discovered that elements are added to executions list if the queryCache is enabled

For hibernate version lower than 3.5.3

In org.hibernate.engine.ActionQueue


and at the Tx end, the transaction tries to be sync to the cache, which is why executions is kept around.
So, I'd recommend to wrap the processor and commit the transaction every X amount of records processed.

Another, very very DIRTY solution is to execute this after your clear(), which
iterates through the executions and syncs them with cache. so this will ONLY work if updated tables != cached tables, and worse, it may break in future hibernate versions. Better to commit periodically instead :)

((SessionImpl) getSession()).getActionQueue().afterTransactionCompletion(true);


...
versiosn higher than 3.5.3 modified the algorithm, so I can't say if it has a bug or not, I'll have to test.

Would you be willing to document this in a new JIRA ticket? If you have something simple we could use to test with, that would be appreciated as well.

Yes, I have been looking for time to do that. Will update this thread with Jira #