We've got a rather lengthy batch process that may end up inserting a large amount of data so we've been liberally using flush and clear on the sesssion to keep memory usage down.

However, running through a profiler I noticed that we were still holding references to our inserted, updated objects after being flushed and cleared.

Traced it down to the ActionQueue class:



Looks like since we have the query cache enabled for a few select queries that our inserts are getting cached in the executable list so that the afterTransactionCompletion method can use them.

Is there any way to have this behave a bit 'better' for our batch update case w/o having our new objects cached or do we need to make a choice of query cache enabled or disabled and live with the outcome?

We could possibly be dealing with 50, 000 to 60, 000 entities for some of our larger batches and I would prefer not to have them lingering in memory for any longer than they are needed.

Just as an example, on one of our larger runs we ended up with an ActionQueue that grew to 140 megs or so. Not so ideal, with the cache criteria turned off the memory consumption was only about 4 megs.

Apparently turning it off isn't an option for us as our reporting will simply choke.

Do I have any other options?

I'm thinking we can batch up our process a bit better, i.e. we're clearing the session more than we need to which results in bringing in multiple instances of support objects which linger around. This will help reduce the amount of clutter but it's not going to get us anywhere near the 4 megs.

I am having the same problem. I have a long running batch that runs out of memory due to the executions collection filling up in the action queue. I am calling flush() and clear() on the session after every 20 saves, but clear() does not clear the executions collection. Is this a bug?

Can anyone suggest (configuration setting?) a means to avoid the executions collection from filling during a single transaction in whick many records are inserted?

Jason.

You need to disable both hibernate.cache.use_query_cache and hibernate.cache.use_second_level_cache by setting both of them to false. This will prevent executions from being recorded.

Well, about a year and a half later and I had to dig up this post again. Looks like whatever we were using with a query cache has gone away so I will now be able to finally turn off the query cache.

This will drastically increase our memory consumption on our bigger processes and I've had to fight with a few of them this week so digging up this post was most excellent, lol.

Seems that the problem remains ...

Anyone from Hibernate team, please respond! Is it a bug?

The behaviour could be clearing relevant query cache when clearing Session ...

Thanks!
Michael.

And another issue, it seems that references of CGLIBLazyInitializer survive SessionImpl.clear.

The problem is, that CGLIBLazyInitializer holds a reference to it's target object. So if I'm using lazy many-to-one or one-to-one associations during transaction, those objects won't be cleared during SessionImpl.clear.

Hibernate guys - please reply! It seems that SessionImpl.clear has several issues and is not working so well ... The problem is critical when handling big amounts of data during single DB transaction.

Thanks!
Michael.

I entered this issue as bug #HHH-3195:

http://opensource.atlassian.com/project ... e/HHH-3195