I have been trying to get bulk inserts working, but continually come across an OutOfMemoryError after around 200,000 inserts. I'm flushing and clearing every 100 inserts, but this doesn't help.

After examining a heap dump, it looks like the problem is that the MySQL JDBC driver is holding onto way too many result sets: about one per insert. It looks like the problem is that the PreparedStatement keeps these open (List<ResultSet> com.mysql.jdbc.StatementImpl.openResults) until the PreparedStatement is closed, or getMoreResults(CLOSE_ALL_RESULTS) is called.

So, why is this in a Hibernate forum? Well, shouldn't the flush process also close all PreparedStatments? I understand that there's a performance hit here... but this is the only way to ensure we're not holding onto resources between flushes - one of the major usages of flush() in the first place. Personally, I'd rather take a performance hit rather than risk taking the VM down.

Any other ideas?
Corey

I've been continuing this investigation as much as time allows, and have determined that Hibernate is indeed calling close appropriately. It wasn't making it to the JDBC layer because the call was intercepted by C3P0 as part of its statement pooling mechanism.

So, given that statement pooling is required by the application, is the problem that C3P0 isn't cleaning up the result sets properly, or that Hibernate isn't following the contract? Here's an excerpt from the C3P0 docs (bold is part of docs!):

Any ResultSets returned by the operation will be proxied and c3p0-managed, meaning that these resources will be automatically closed if the user does not close them first when this Statement is closed or checked into the statement cache. Any other resources returned by the operation are the user's responsibility to clean up!

If anybody knows anything about this and can help me on this, it would be greatly appreciated!