J2EE (websphere) + Hibernate + ThreadLocal

[no]

Hello,

According to Hibernate team the standard way to use hibernate in a J2EE
environement (on a session per request basis) is with the HibernateUtil
class describe here :

http://www.hibernate.org/hib_docs/reference/en/html/quickstart.html

notice :
public static final ThreadLocal session = new ThreadLocal();
(in order to store the hibernate session)

In an other hand, some say that you must not use ThreadLocal within a
J2EE application server

"ThreadLocal and thread pools just don't mix"
"Besides, it's a huge security risk"

look at:
http://www.devwebsphere.com/devwebsphere/2005/06/dont_use_thread.html


So, what would be "the regular" way of using hibernate ?

 

[Raymond DeCampo]

Hello,

According to Hibernate team the standard way to use hibernate in a J2EE
environement (on a session per request basis) is with the HibernateUtil
class describe here :

http://www.hibernate.org/hib_docs/reference/en/html/quickstart.html

notice :
public static final ThreadLocal session = new ThreadLocal();
(in order to store the hibernate session)

That is just an example and may not be appropriate in all environments.
Within an application server you have other tools at your disposal
that are more appropriate. I would recommend simply creating a
hibernate session in the servlet doPost() or doWork() method and passing
it to your business logic code as a parameter. Don't forget to close it
in a finally clause.

In an other hand, some say that you must not use ThreadLocal within a
J2EE application server

"ThreadLocal and thread pools just don't mix"
"Besides, it's a huge security risk"

look at:
http://www.devwebsphere.com/devwebsphere/2005/06/dont_use_thread.html

I'm not sure if I totally agree with this. However, in a J2EE
environment, you must be aware that threads are shared and re-used for
subsequent requests. Therefore you must leave the thread in a good
state for the next request.

So, what would be "the regular" way of using hibernate ?

Ray

 

[James McGill]

So, what would be "the regular" way of using hibernate ?

In JBoss , you make the container give you the SessionFactory via JNDI,
and get the Session from there only when you need it.

http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossHibernate3

For WebSphere, there doesn't seem to be this level of integration
available, but you can at least configure the Hibernate SessionFactory
to use WebSphere's pooled connections.

http://www-128.ibm.com/developerworks/websphere/techjournal/0409_patil/0409_patil.html

Building the SessionFactory is the heavy lifting, and you only want to
do it once, ever, if you can manage that. Once you have that, the
Session objects are really light.

I wouldn't mess with threads at all. Are you sure the JBoss page you
referenced, is talking about J2EE usage specifically?

 

[robert]

no escreveu:

Hello,

According to Hibernate team the standard way to use hibernate in a J2EE
environement (on a session per request basis) is with the HibernateUtil
class describe here :

http://www.hibernate.org/hib_docs/reference/en/html/quickstart.html

notice :
public static final ThreadLocal session = new ThreadLocal();
(in order to store the hibernate session)

In an other hand, some say that you must not use ThreadLocal within a
J2EE application server

"ThreadLocal and thread pools just don't mix"
"Besides, it's a huge security risk"

look at:
http://www.devwebsphere.com/devwebsphere/2005/06/dont_use_thread.html


So, what would be "the regular" way of using hibernate ?

I personally use the threadLocal that comes with Spring's open session
in view (OSIV):

http://www.springframework.org/docs...ibernate/support/OpenSessionInViewFilter.html

Its configured in the filter section of your web.xml .

My recollection while researching the classic lazy initialization
exception is that osiv is one of the few examples where threadlocal is
implemented correctly.

My guess is HibernateUtil is just fine considering that the hibernate
people are largely employed by jboss, and are in general are hostile to
spring.

HTH,
Robert
http://www.braziloutsource.com/