Hi,
is there a possibility to achive transaction handling by database and not by jdbc? I've a spring application and I'm using the org.springframework.orm.hibernate3.HibernateTransactionManager. Due to a large amount of inserts my application runs out of memory. When I remove the transactionManager everything works fine, but I need to process everything in one transaction. I think this behaviour is because then the transaction and it's data is handled by the RDBMS.

Any suggests? Thx 4 help

Do all of the inserts depend on each other? If not, try committing the transaction every few inserts. I'm pretty sure (someone correct me if I am wrong) that hibernate stores transaction data in memory until it is committed. My guess as to why you aren't running out of memory when you don't use the TransactionManager is that you aren't using any transactions at all and the data is being directly committed to the database. What RDBMS are you using?



--please rate post if it helps--

Thx for your reply, but that's what I've mentioned. I can't do all the stuff in multiple transactions. When I'm not using Hibernate and do everything with JDBC and self written SQL-Queries, everything works. My RDBMS Postgres is then handling the transaction and doesn't cache all the stuff in memory. Is the no way to achieve tis behavior with Hibernate, too?

It's not the transactional behaviour that is causing your memory problems. It is the size of your Hibernate session. By default Hibernate only flushes its session at commit time. When you manage your transactions at the application level, the session keeps growing and growing. What you call the database handling the transactions, is actually just autocommit behaviour causing Hibernate to flush for each statement. It's useless in your situation though.

The solution to your problem would be to do a flush of your Hibernate session from time to time. This causes Hibernate to send the SQL requests needed to synchronize the database and your Hibernate session. If you have Spring manage your transactions at the application level, a flush does not automatically imply a commit. After the flush you can clear your session, in order to free up the memory used by the session.

HTH
Jurgen

Hi Jurgen,

thank you for your answer. I'm already doing a flush() and clear(), but the session is still growing.

I use spring with a hibernateinterceptor and transactionInterceptor around my daos to ensure one transaction. Perhaps I did something wrong. May you post a simple example spring-configuration, please?

I had a similar situation, We re-designed to make sure there is no single huge commit. Transactions were split into more finer units of work. It improves performance, helps a lot in maintenance of code too. Re-evaluate to see if you can break the transactions.