transaction performance

chris40 · **Posted:** Mon Mar 13, 2006 2:43 pm

We are using Hibernate 3.0.5 and encoutering performance problems with long transactions.

Exemple :
In one transaction, creation of 10000 objects of same type takes 1250 sec.

Same objets, creation of 100 x 100 objects (with tx.begin/tx.commit) takes 32 sec.

We are using JTA.

May someone can you explain this ?

simonwillnauer · **Posted:** Mon Mar 13, 2006 4:08 pm

Hey, what's the sice of your hibernate.jdbc.batch_size
do you use it at all? I guess that your gain a benefit from using the jdbc batch size and flushing your session after commiting your transaction.
The second approach might be less memory consuming as well.

simon

chris40 · **Posted:** Tue Mar 14, 2006 3:14 am

No, setting jdbc.batch_size doesn't seem to solve my problem, performance is still very very poor.

Commiting the transaction only at the end of the job is a very important point for us ; of course, we don't have 100k objects to create, it is just a performance-test point of view.

But we have more than 1000 objects to be created/updated, and they take more than 10 minutes to be executed. That's why we are looking for performance improvements.

Doing a regularly commit divides by 5 this time, but doing that, we are not able to rollback if a the end an update problem is encountered.

So this is a big problem for us today.

As an exemple, I did a simple JDBC/Postgres test doing 100k insertions. Doing begin/100k inserts/commit or 100x100 begin/inserts/commit takes the same time. So it is not a Postgres problem.

stefanm · **Posted:** Tue Mar 14, 2006 8:23 am

Maybe you should try to call only

Code:

session.flush();
session.clear();

instead of committing regularly.
I suppose this should also improve your performance.

best regards,
Stefan

ekupcik · **Joined:** Sun Oct 09, 2005 6:36 am **Posts:** 19

Do you just create objects or does your test also include queries? Hibernate checks whether any persistent instances need to be flushed to the DB before it runs the query (as the result of the query might depend on the values of some of the modified objects). The larger your session the longer this test takes. So i might be a good idea to flush the objects manually and clear the session from time to time or to use some custom Interceptor to handle the is-dirty checks. Or you could tell hibernate not to flush the session before running a query(Session.setFlushMode) or use StatelessSessions

chris40 · **Posted:** Tue Mar 14, 2006 2:07 pm

Only for this test, I do just inserts.

flushing/clearing the session doesn't resolve the problem ; the gain is only about 15% of executing time.

In the final application, we are of course doing query/inserts/updates.

chris40 · **Posted:** Thu Mar 23, 2006 3:06 am

I still have the problem ... anybody can help me ?

steckemetz · **Posted:** Thu Mar 23, 2006 4:43 am

Can you use the stateless session ?
And can you post the code ?

chris40 · **Posted:** Thu Mar 23, 2006 4:58 am

[quote="steckemetz"]Can you use the stateless session ?
[/quote]
To use stateless session, have I to upgrade to Hibernate 3.1 ? I am currently using Hibernate 3.0.5. I will test with latest Hibernate 3.1.3 version. Hope to test it today.

chris40 · **Posted:** Thu Mar 23, 2006 10:46 am

No, I can't use StatelessSession because of the lack of interceptors, of Set management, and so on.

Hibernate 3.1.3 seems a few more quicker than 3.0.5.

But a bulk insertion/update in a long or big transaction is still very very slow.