Announcement Announcement Module
Collapse
No announcement yet.
How Sessions bound to JTA with Hibernate Tx mgr_lookup_class Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How Sessions bound to JTA with Hibernate Tx mgr_lookup_class

    If you're leveraging Hibernate's transaction manager_lookup_class to integrate with BEA's transaction manager (see below), does this leverage Spring's TransactionSynchronizationManager behind the scenes somehow? The documentation says use org.springframework.transaction.jta.JtaTransaction Manager for global transactions (we are doing global), but you can use the Hibernate lookup class too. I'm just curious how are the Session threads bound to the JTA transaction when I'm not using the Spring JtaTransactionManager explicitly in the applicationContext.xml.

    Note that I have it working; this is more addressing the "how" is it working. Just a thirst for understanding...

    Thanks,
    Lou

    Code:
          <property name="hibernate.transaction.manager_lookup_class">
             net.sf.hibernate.transaction.WeblogicTransactionManagerLookup
          </property>

  • #2
    When using Spring's HibernateTransactionManager or JTATransactionManager, any transaction manager lookup you configure in the session factory is purely for Hibernate, so it can properly synchronize a JVM level cache in a JTA environment. It doesn't really affect Spring's transaction handling. With HibernateTransactionManager, Spring will simply manage transactions via the Hibernate transaction apis, which ultimately will just use the simple connection level transaction APIs (except if override the default hibenrate level transaction handling settings, which you would never do, since this is best managed at a Spring level if you want to go with JTA). When using JTATransactionmanager, Spring will use the JTA level APIs to 'manage' transactions. In this case of course, it's more of a delegation to the JTA transaction manager, which is the real manager of the transaction. But with either HibernateTransactionManager of JTATransactionmanager, Spring will properly synchronize the Hibernate Sesion to the transaction, regardless of the session factory associated transaction manager lookup being set.

    On the other hand, when doing Contaier Managed Transactions (CMT), as in an EJB environment, with no Spring trnasaction manager in the picture at all, Spring _does_ take advantage of and in fact needs the sesion factory defined transaction manager lookup so it can associate the the sessions with a transaction. It would have no way to get the current transaction otherwise.

    Comment


    • #3
      Thanks for the thorough description. Applying what you have said to session management, I think it is safe for me to use SessionFactoryUtils.getSession(sesFactory, false) in a BEA CMT configuration, if you know that the session should be bound to a thread. I ask this question because in the Spring source code for HibernateTemplate, you do some extra checks with the session with regard to the transaction manager as follows:

      Code:
      	public Object execute&#40;HibernateCallback action&#41; throws DataAccessException &#123;
      		Session session = &#40;!isAllowCreate&#40;&#41; ?
      				SessionFactoryUtils.getSession&#40;getSessionFactory&#40;&#41;, false&#41; &#58;
      				SessionFactoryUtils.getSession&#40;
      						getSessionFactory&#40;&#41;, getEntityInterceptor&#40;&#41;, getJdbcExceptionTranslator&#40;&#41;&#41;&#41;;
      		boolean existingTransaction = TransactionSynchronizationManager.hasResource&#40;getSessionFactory&#40;&#41;&#41;;
      		if &#40;!existingTransaction && getFlushMode&#40;&#41; == FLUSH_NEVER&#41; &#123;
      			session.setFlushMode&#40;FlushMode.NEVER&#41;;
      		&#125;
      		try &#123;
      			Object result = action.doInHibernate&#40;session&#41;;
      			flushIfNecessary&#40;session, existingTransaction&#41;;
      			return result;
      		&#125;
      		catch &#40;HibernateException ex&#41; &#123;
      			throw convertHibernateAccessException&#40;ex&#41;;
      		&#125;
      		catch &#40;SQLException ex&#41; &#123;
      			throw convertJdbcAccessException&#40;ex&#41;;
      		&#125;
      		catch &#40;RuntimeException ex&#41; &#123;
      			// callback code threw application exception
      			throw ex;
      		&#125;
      		finally &#123;
      			SessionFactoryUtils.closeSessionIfNecessary&#40;session, getSessionFactory&#40;&#41;&#41;;
      		&#125;
      	&#125;
      My feeling is this would not apply where I expect the session because I do not want to alter FlushMode, nor do I want to flush and close the session. Would you agree? Conversely, I think more care would be required if I did *not* know if the session was yet bound to the thread. In these cases, I've been resorting to the HibernateTemplate's convenience methods or using HibernateCallback.

      Thanks,
      Lou

      Comment

      Working...
      X