Hi,

We are developing a web application which uses hibernate for data persistence. There is a confusion regarding when to open and close hibernate session. We are planning to use JNDI bound session factory. Is it a good practice to call sessionFactory.openSession() within the methods in the DAO class and call session.close() in the finally block in those methods? I have read that filters also can be used for that. We are confused on which method to adopt. Please give your valuable suggestions on this.

This is a sample code we wrote in the DAO class:


public void persist(TestEntity transientInstance) {
try {
HibernateUtil.beginTransaction();
HibernateUtil.getCurrentSession().save(transientInstance);
HibernateUtil.commitTransaction();
} catch (RuntimeException re) {
re.printStackTrace();
}finally {
HibernateUtil.closeSession();
}
}

This is our HibernateUtil class:

public class HibernateUtil {

private static SessionFactory sessionFactory;
private static final ThreadLocal threadSession = new ThreadLocal();
private static final ThreadLocal threadTransaction = new ThreadLocal();

public static Session getCurrentSession() {

Session s = (Session) threadSession.get();

// Open a new Session, if this thread has none yet
try {
if (s == null) {
InitialContext ic=new InitialContext();
// JNDI bound session factory
sessionFactory=(SessionFactory)ic.lookup("java:hibernate/SessionFactory");
s = sessionFactory.openSession();
threadSession.set(s);
}
} catch(NameNotFoundException nnfe) {
// For situations where JNDI bound session factory is not supported
sessionFactory = new Configuration().configure("hibernate.cfg.xml").buildSessionFactory();
s = sessionFactory.openSession();
threadSession.set(s);
} catch(NamingException ne) {
System.out.println(ne.toString());
} catch (HibernateException ex) {
System.out.println(ex.toString());
}
return s;
}

public static void closeSession() {

try {
Session s = (Session) threadSession.get();
threadSession.set(null);
if (s != null && s.isOpen()) {
s.close();
}
} catch (HibernateException ex) {
System.out.println(ex.toString());
}
}

public static void beginTransaction() {

Transaction tx = (Transaction) threadTransaction.get();
try {
if (tx == null) {
tx = getCurrentSession().beginTransaction();
threadTransaction.set(tx);
}
} catch (HibernateException ex) {
System.out.println(ex.toString());
}
}

public static void commitTransaction() {

Transaction tx = (Transaction) threadTransaction.get();
try {
if(tx != null && !tx.wasCommitted() && !tx.wasRolledBack()) {
tx.commit();
}
threadTransaction.set(null);
} catch (HibernateException ex) {
rollbackTransaction();
}
}

public static void rollbackTransaction() {

Transaction tx = (Transaction) threadTransaction.get();
try {
threadTransaction.set(null);
if ( tx != null && !tx.wasCommitted() && !tx.wasRolledBack() ) {

tx.rollback();
}
} catch (HibernateException ex) {
System.out.println(ex.toString());
} finally {
closeSession();
}
}
}

Thanks & Regards
Merin

Merin:

You definitely do not want to do this:


Your DAO should not be starting and committing transactions, the transactions should encapsulate your business logic. For instance, what would happen if your business rules required two separate entities be persisted with rollback on both in case of failure. That's why I always code a service layer and deal with transactions there. If your project is small enough, you can get away with dealing with transactions directly in your MVC layer.

As far as session management is concerned, it really depends on how you want to code your MVC layer. If you would like to lazy load things in your view, then you are best off using a servlet filter to open and close the sessions in the filter chain (this is typically called an Open Session In View filter) and you can find the details here: http://www.hibernate.org/43.html . The thread local pattern that you are currently using is a bit deprecated, in that the Hibernate session can be bound to a thread automatically, see http://www.hibernate.org/hib_docs/v3/re ... nt-session for information about the contextual sessions. That way, any call to SessionFactory.getCurrentSession() will return the thread (or JTA) bound Session. This is a nice pattern to use, check out the CaveatEmptor demo application for a more updated HibernateUtils. Happy coding!

Hi Ananasi,

Thanks for your response. I understand from your reply that beginTransaction and commit should not be done in DAOs. Servlet Filter also seems to be a bad choice. I actually don't like to use filter because all requests may not require a database transaction.

According to you,
>>That's why I always code a service layer and deal with transactions there.

What do you mean by service layer and how do you implement that? Could you please send a sample code? Our application has a presentation layer and business implementation layer before dao layer. Which is the best place to include the transaction code?

Is JTA the best option for a web application?

Is this code ok?

try {
UserTransaction tx = (UserTransaction)new InitialContext() .lookup("java:comp/UserTransaction");
tx.begin();
// Do some work
factory.getCurrentSession().load(...);
factory.getCurrentSession().persist(...);
tx.commit();
} catch (RuntimeException e) {
tx.rollback();
throw e; // or display error message
}

I am really confused on how to proceed. Please help.

Thanks & Regards
Merin
[/quote]

1) If you have JTA available, I would definitely use that. Set the hibernate.current_session_context_class property to "jta" and whenever you start a JTA transaction, the getCurrentSession() call will return the Hibernate session bound to that JTA transaction automatically (session-per-request semantics). From the javadocs of org.hibernate.context.JTASessionContext:



2) Service layer = business layer, it's just semantic differences. Definitely start and commit your transactions there to encapsulate your business logic. For example:


If you want, you can still use the thread bound transaction demarcation (the ThreadLocal in your current HibernateUtils) to begin, commit and rollback transactions as needed, providing further abstraction, which would make the code look like this:



Again, check out http://www.hibernate.org/400.html and look at the HibernateUtils class there (auction.persistence.HibnerateUtil). It's the best start, notice the lack of ThreadLocal variables to hold a Session.