We have the standard design where the Session Bean calls Hibernate DAO'.s. Whicn in turn creates new hibernate session every time when we make a call to the Hibernate DAO. From my understanding Hibernate Session is wrapper around around database connection with hibernate session features. Is creating hibernate session expenise evry time when making call to the Hibernate DAO's.

You could use ThreadLocal hibernate session pattern (HibernateUtil, example is in the reference documentation). But, as you know, all "games" with threads and singletons are not desirable inside EJB environment. But in my current project we use this pattern with JBoss.

About hibernate session and JDBC connection, be sure, each new hibernate session instance inside one container managed transaction contains the same JDBC connection.

What about the cost of a new hibernate session creation inside a container managed transaction, it is the question to the authours. It interests me too :)

--
Leonid

Hello,

I too was doing a similar thing with my Session Beans accessing my Hibernate DAOs.

I'd like to suggest investigating the Spring Open Session in View pattern using Spring's filter iteself or a hand-rolled variant. I have successfully migrated my application to use Spring and am loving it. Development has been greatly simplified.

If you don't want to expose yourself to the overhead of another framework, consider the simple HibernateUtil class from http://caveatemptor.hibernate.org/. It solves most of the common issues with Hibernate integration.

I'm using Bea Weblogic Server. It's so strange that the thread is unique for any method calls to a Stateful Session Bean (from the web tier). In the case of concurrent accesses, it uses different threads.

As explained above, we could not use ThreadLocal to have just one session per transaction.

We are using DAO pattern and SFSB's as session facade.

So, What to do now?

Any comment is welcome,

Amin Emami

If you don't have a guarantee that you have a thread-per-transaction association using threadlocal becomes dangerous of course. Either you do manual passing around of your sesison, or you find another way to bind your session to the transaction scope in a way you can use in your situation.

As I said all games with threads and signletons are dangerous in EJB environment.
Please, read this
http://www.javaworld.com/javaworld/jw-01-2001/jw-0112-singleton_p.html
It describes why you should not use singletons inside EJB environment. If you understand it, you understand why you should not use ThreadLocal pattern (it is not portable approach). ThreadLocal pattern works for JBoss, but for others... (The number of classloaders and JVMs for one application server is not limited by specification)

In my current project we are still using HibernateUtil with thread local pattern, but we are refactoring (in lazy mode) all EJB and DAO code to use passed hibernate Session. So each DAO gets opened hibernate session like constructor or method argument. When lazy refactoring is done we will rewrite HibernateUtil for it does not use ThreadLocal pattern.

Regards

Thank you for reply.

I have another problem with Threads, Transactions and Sessions!
I have applied DAO pattern and I have some DAO classes which are responsible to handle all the entity's life cycle. On the other hand, I use SFSB's for Session Facade.

There'll be no problem in ONE transaction but imagin a situation where in transaction 1 I find the bean (through its DAO1 and using ThreadLocal for getting the session)and keep the entity object (bean) as a SFSB's member. In transaction 2, when I use another DAO2, given session is different to the first. This causes some problems for developers.

I think I need session-per-SFSB !!! and pass the session manually to all DAO's. I prefered not to show the session to the developers before.

What's your idea about this conflict? Which situation is better?

Thanks in advance,

Amin Emami