Self managed Hibernate Session as JTA Synchronization

ivelin · **Joined:** Mon Nov 03, 2003 9:17 am **Posts:** 3

Wanted to validate with the group a design pattern that I've been using for a little while and appears to work well.

This applies to applications that use JTA, either through wrapping the HttpReuqest with a Transaction [1], Bean Managed
Persistence EJBs or some other kind of middle tier transaction wrapped business logic.

The solution exposes a single getSession() method that can be called anywhere within a Transaction. Let's call it JTASessionFactory.getSession()

The client code that invokes this method, receives the session, uses it and leves it alone, without having to explicitly flush or close.

What happens in getSession() is the following:
1) The first time it is invoked within the scope of the current transaction, a new session is created via SessionFactory.openSession() and a Synchronization listener is attached to the tx.

2) Consequitive calls to getSession() within the scope of the same transaction will return the same session instance.

3) When the transaction is ended (commit or rollback), the synchronization listener flushes and closes the session.

This pattern targets the following benefits:

1) The client code does not have to use repeatedly openSession/try/catch/finally blocks, which are error prone. Just getSession()

2) The session uses one connection from the underlying DataSource pool throughout the duration of a transaction.

3) The session cache is utilized throughout the whole transaction.

4) flush() may not need to be invoked explicitly unless there is specific application need for it like mixing straight JDBC with Hibernate.

5) There is no concern of multiple threads using the same session, because application servers use ThreadLocal to carry a transaction in the same VM.

Let me know if this is a feasible solution.
If it is, I can send the code for CVS.

Ivelin

Resources:
[1] TransactionFilter
http://java.sun.com/blueprints/code/adv ... .java.html

gavin · **Posted:** Thu Nov 06, 2003 11:47 am

Yes, this is a good solution and is not very different to what I do.

ivelin · **Joined:** Mon Nov 03, 2003 9:17 am **Posts:** 3

Does your code for this solution ship with hibernate?
I have mine as a JBoss MBean which depends on the current HibernateService MBean. It registers in JNDI and is then looked up by the clients through a static helper method.

Ivelin

camronlevanger · **Joined:** Mon Dec 22, 2003 8:25 am **Posts:** 2

Hey guys,

Just started playing with hibernate, this is what i would like to do, is there anywhere i can find a tutorial or example that shows how to do this? I have been looking for a while now and can't seem to find anything.

Thanks,

Cam

camronlevanger · **Joined:** Mon Dec 22, 2003 8:25 am **Posts:** 2

Just wanted to clarify, i am looking for a solution like this, but not interested in JTA. Also prob deploy to tomcat or jetty, no EJB container.

Thanks again.

Cam

shreyank · **Joined:** Fri Feb 20, 2004 12:23 pm **Posts:** 10

Using weblogic 8.1 and hibernate 2.1.1.
I am using this same design pattern but am running into a problem:

I had registered my javax.transaction.Synchronization object with the JTA transaction and put the session.close() call in Synchronization.beforeCompletion(). This worked in the normal case. However, beforeCompletion() only gets called before a commit and not a rollback. So if i have a runtime exception during my application code then beforeCompletion() does not get called.

So I moved my session.close() call to afterCompletion(). However, my setup is having problems with this. The code works the first time through. But anytime after that an exception is thrown in the afterCompletion() method:

Code:

- SQL Error: 0, SQLState: null
- The transaction is no longer active - status: 'Committed'. No further JDBC access is allowed within this transaction.
- Cannot close connection
java.sql.SQLException: The transaction is no longer active - status: 'Committed'. No further JDBC access is allowed within this transaction.
   at weblogic.jdbc.wrapper.JTSConnection.checkIfRolledBack(JTSConnection.java:118)
   at weblogic.jdbc.wrapper.JTSConnection.checkConnection(JTSConnection.java:127)
   at weblogic.jdbc.wrapper.Connection.preInvocationHandler(Connection.java:70)
   at weblogic.jdbc.wrapper.JTSConnection_oracle_jdbc_driver_OracleConnection.getWarnings(Unknown Source)
   at net.sf.hibernate.impl.BatcherImpl.closeConnection(BatcherImpl.java:267)
   at net.sf.hibernate.impl.SessionImpl.disconnect(SessionImpl.java:3203)
   at net.sf.hibernate.impl.SessionImpl.close(SessionImpl.java:549)
   at test.SynchronizedObject.afterCompletion(SynchronizedObject.java:20)
   at weblogic.transaction.internal.ServerSCInfo.callAfterCompletions(ServerSCInfo.java:853)
   at weblogic.transaction.internal.ServerTransactionImpl.callAfterCompletions(ServerTransactionImpl.java:2658)
   at weblogic.transaction.internal.ServerTransactionImpl.afterCommittedStateHousekeeping(ServerTransactionImpl.java:2556)
   at weblogic.transaction.internal.ServerTransactionImpl.setCommitted(ServerTransactionImpl.java:2588)
   at weblogic.transaction.internal.ServerTransactionImpl.globalRetryCommit(ServerTransactionImpl.java:2386)
   at weblogic.transaction.internal.ServerTransactionImpl.globalCommit(ServerTransactionImpl.java:2315)
   at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:255)
   at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:221)
   at weblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:289)
   at weblogic.ejb20.internal.StatelessEJBObject.postInvoke(StatelessEJBObject.java:141)
   at test.TestSessionBean_188pz4_EOImpl.testMethod(TestSessionBean_188pz4_EOImpl.java:422)

Does my problem have anything to do with this previous post from Juergen?:
http://forum.hibernate.org/viewtopic.php?t=926920

Thanks for your help,
-shreyank purohit

jim_cakalic · **Joined:** Fri Jan 23, 2004 3:35 pm **Posts:** 2

Hi, ivelin. This sounds interesting. Is it possible for you to contribute the code for this class?

jhoeller · **Posted:** Tue Mar 09, 2004 8:10 am

FYI, the Spring Framework provides a pre-built solution for the session/transaction association problem - not just for JTA but for any of its supported transaction strategies. You have the same problem when working with native Hibernate transactions, if demarcating high-level transactions that span multiple DAO invocations.

In the JTA case, Spring doesn't rely on JTA's synchronization mechanism, as this is just available via the JTA TransactionManager - to be located in a server-specific way. Spring rather applies its own transaction synchronization mechanism which will work with any transaction strategy.

What you typically do with Spring in an EJB environment is demarcate an additional Spring transaction that spans your DAO invocations: Spring's JtaTransactionManager will seamlessly participate in existing JTA respectively EJB CMT transactions but additionally perform transaction synchronization.

Session lookup works via SessionFactoryUtils.getSession, or implicitly through using Spring's HibernateTemplate. See the article at http://www.hibernate.org/110.html for details.

Juergen

amin_emami · **Joined:** Sat May 29, 2004 2:32 am **Posts:** 8

Ivelin,

Very goods solution but I would like to know what transaction mode this solution needs; User-Transaction or Container-Managed.

We use Stateful Session beans for Session Facade in our architecture and every transaction begins here. SFSB's are container-managed. We've also applied DAO patterns and we desire to create session automatically, not to open by developers. Developers just use DAO's to handle the beans (hibernate session is cached behind DAO).

Any comments by other folks are welcome.

Amin Emami

Fuseboy · **Joined:** Mon Mar 08, 2004 12:32 pm **Posts:** 7

We're doing this as well; it works nicely.

Rather than have the first call to getSession() start the session, however, we're using CGLIB to wrap certain objects with a method-call interceptor that that starts and commits (or rolls back) the transaction. We use them as a form of light weight stateless session bean.

baliukas · **Posted:** Thu Aug 26, 2004 6:10 am

jhoeller wrote:

In the JTA case, Spring doesn't rely on JTA's synchronization mechanism, as this is just available via the JTA TransactionManager - to be located in a server-specific way. Spring rather applies its own transaction synchronization mechanism which will work with any transaction strategy.

Nobody needs TransactionManager in application, Statefull bean is a standard way to register transaction callback.

akula · **Joined:** Tue Sep 06, 2005 11:47 am **Posts:** 1

shreyank - were you able slove the problem you mentioned above? if so, can you share what you did to resolve the issue with JTA synchronization?

Using JTA synchronization how do you handle closing of seesion in case of a rollback. App. server tries to cleanup the session/connection before JTA synchronization.aftercompletion is invoked. any ideas on how to close the connection in CMT, other than filters is appreciated.

guid · **Joined:** Thu Dec 16, 2010 3:07 am **Posts:** 5

First of all, I appreciate your effort in doing the research and pointing out as to what the issue is. However I do like to break in here and say that I have a question to ask and that would be whether the code for the given solution here ship with the process of hibernating. I can see that one guy has already asked this question. But you have not given any answer for it. Hence, please do give us a report on that!