Hibernate session gets stuck when trying to flush data..

[spring007]

Hi Everyone,

Currently I am facing a problem in which Hibernate session is executing an SQL query against the Oracle database but then hibernate never gets control back and looks as if waiting for something forever.

I am using spring framework's hibernate support for database persistence.

I debugged the application and saw that Hibernate Session is executing a prepared statement underneath when it tries to flush data to the database and that's when everything gets hung.

My application creates multiple threads using JDK5 ThreadExecutor service and then, each thread invokes a new DAO instance which extends spring framework's HibernateSupport class. I am not sure why Hibernate acts this ways. All the threads are under the same transaction. So we have a kind of one transaction and one DAO per thread logic.

Any feedback will be highly appreciated.

Thanks.

[Alarmnummer]

Hi Everyone,

My application creates multiple threads using JDK5 ThreadExecutor service and then, each thread invokes a new DAO instance which extends spring framework's HibernateSupport class.

Why do you create new dao`s? Why don`t you give a reference from a single dao, to all the threads?

I am not sure why Hibernate acts this ways. All the threads are under the same transaction. So we have a kind of one transaction and one DAO per thread logic.

What do you mean with under the same transaction? If there is a big transactions started before the threads are started, and the threads do call to the dao, you have a serious problem. The HibernateSupport class retrieves the session (transaction) from some kind of threadlocal. But your threads in the threadpool don`t have this threadlocal set.

And how do your doa`s get a reference to the SessionFactory? Do you create that one every time you need it?

[spring007]

Actually, I need to create new DAOs because since each thread executes concurrently, I cannot mark DAOs as singleton else all threads are going to interfere with same bunch of code, we don't have methods described as synchronized. Also, if I make the methods synchronized, it's going to slow down the performance which is defeating the main objective.

Also, about sessionFactory getting set, it should be set by spring framework when it creates DAO's new instance through their IOC principle and sessionfactorybean is a singleton, so we should have the same session factory set in all DAOs.
When the threads get invoked, there is already a big transaction and the threads will be running under it.

Let me know if you need more information and also if you think that this situation is overall a big problem.

[Alarmnummer]

Actually, I need to create new DAOs because since each thread executes concurrently, I cannot mark DAOs as singleton else all threads are going to interfere with same bunch of code, we don't have methods described as synchronized. Also, if I make the methods synchronized, it's going to slow down the performance which is defeating the main objective.

The HibernateDao is thread safe and you only have to synchronize if you share (mutable) data. I dont think this is the case.. If you don`t share data, but only 'methods', you do not need to synchronize.

so I would reconcider your approach.

Also, about sessionFactory getting set, it should be set by spring framework when it creates DAO's new instance through their IOC principle and sessionfactorybean is a singleton, so we should have the same session factory set in all DAOs.

Ok

When the threads get invoked, there is already a big transaction and the threads will be running under it.

How do you know this? Do you give the session to the dao? Do you attach the session that is created by your main thread to the pooled threads. If not, your pooled threads don`t run under the same transaction (if any transaction at all). I think this is the source of your problem.

[spring007]

Thanks for your guidence.

I will make the DAO as singleton and see if I get the "stuck session problem" again.

Also, since I create a new DAO every time a thread is created, I am thinking that new session will be associated per thread. Even if it maintains the same session, it shouldn't matter in my case as the data the individual threads shall deal with, will represent different rows in a database.
About the transaction, there is a JTA transaction existing and is created by top sitting MDB and is simply propagated down the line. So, I am thinking that every new thread is associated with the same transaction.

I have no idea how hibernate works when threads, session and transaction, all three of them come together. Looks like my problem is a result of this.

Let me know if you need more information and thanks for your support.

[Alarmnummer]

Thanks for your guidence.

I will make the DAO as singleton and see if I get the "stuck session problem" again.

You still have problems, you pooled thread doesn`t have the same (if any) session bound to a thread local as the main thread. So for the dao, the calls that are made, are done on different session (read different transactions).

Also, since I create a new DAO every time a thread is created, I am thinking that new session will be associated per thread.

The session is created by the main thread. That session is bound to that main thread (by a thread local). Your pooled threads don`t have any session bound to some kind of thread local.

So, I am thinking that every new thread is associated with the same transaction.

I don`t think this is the case.

I have no idea how hibernate works when threads, session and transaction, all three of them come together. Looks like my problem is a result of this.

Yes.. but please try to understand how the sessions and threads work. You pooled threads don`t use the same transaction as the main thread. So everything they do on the dao, is not of any interest of the transaction you started.

[spring007]

That means the heart of the problem is that the flushing session is not attached to the main transaction and so is facing problems while flushing data.

Does that mean that the problem could be resolved if I keep the same instance of Session across the threads and have the main JTA transaction attached to it. (which makes the situation as same transaction, same session and many threads) I am not sure if using ThreadExecutor from JDK 5 version would accomplish this.

Are you aware of any other approach to achieve concurrent database update with Hibernate + Spring in general then and if this will satisfy the conditions specified above paragraph.

Thanks a lot for your invaluable guidance.

[Magyusz]

We are using only one own thread. HTTP Request-Response threads put objects to a blocking queue, own thread takes them an works with them, and we are facing the same problems mentioned above.

Can you recommend some hints to create our own Transaction interceptor if it isn't possible to handle this problem (using declarative transactions in own threads) with the Spring's one?