Hello,

I've managed to configure Hibernate to be used with a Spring framework based application and use JTA environment provided with JOTM. The whole thing works, but I have a couple of questions:

1. If I use only manual (with UserTransaction provided by JOTM) TX demarcation, do I have to configure <hibernate.transaction.factory_class> ?

2. If I don't intend to use JVM-level cache, do I have to configure <hibernate.transaction.manager_lookup_class> ?

3. When I boot the JOTM, I publish the UserTransaction under "java:comp/UserTransaction" JNDI name on RMI registry. If I want to change this name, do I have to configure jta.UserTransaction?

Regards,
Horia

I assume you're working with Hibernate 2.1 that auto-detects JTA transaction without explicit Hibernate Transaction management.

ad 1.
If you don't use Hibernate's Transaction interface (and thus, don't use Spring's HibernateTransactionManager), you don't need to configure transaction.factory_class.

ad 2.
Correct, you don't need to specify transaction.manager_lookup_class if you don't use the JVM-level cache, as proper afterCompletion callbacks for the latter is TransactionManagerLookup's sole purpose.

ad 3.
No, this is just necessary if you use Hibernate's Transaction interface. You do external transaction management via JTA on Hibernate 2.1: Hibernate does not touch the UserTransaction then.

If you're currently demarcating transactions on UserTransaction directly, note that this will not give you reuse of Hibernate Sessions within transactions, even with Spring!

If you use Spring's JtaTransactionManager (which delegates to a specified JTA UserTransaction underneath) instead, you'll get proper reuse of Sessions and proper JVM-level caching without specifying a Hibernate TransactionManagerLookup (due to its own synchronization mechanism).

Spring's PlatformTransactionManager interface is even simpler than JTA's UserTransaction, so demarcating with it should not cause any hassle. And of course, if you choose to work with Spring's transaction abstraction, you can use more convenient means of demarcation: programmatic via TransactionTemplate or declarative via TransactionProxyFactoryBean.

Juergen

Hello and 10x,

It worked. (I mean delegating tx management to spring's jta wrapper and than working with spring's tx api)

What exactly do you mean by session reuse? Is it that I can open and close repeatedly a session provided by the same session factory inside that same tx? Something like this:
----------------------------------------------
//begin tx (with spring tx api)

Session ses = sf.openSession();
//do some work
ses.flush();
ses.close();

//open again a session
ses = sf.openSession();
//do some work
ses.flush();
ses.close();

//commit tx
----------------------------------------------

As for the programatic tx demarcation provided by spring, in simple scenarios (with no suspend, resume or join scenarios) I surely preffer JTA api: what can be simpler than utx.begin() - utx.commit()/utx.rollback() :) ?

Regards,
Horia

Regarding Session reuse: If you work with Spring's HibernateTemplate or SessionFactoryUtils.getSession/closeSessionIfNecessary, you will automatically receive the same Session instance within a transaction, no matter if by HibernateTransactionManager or JtaTransactionManager.

This allows to leverage Hibernate's first-level cache throughout a transaction and is more efficient than using multiple short-lived Session instances. Furthermore, it will automatically guarantee proper JVM-level cache callbacks at transaction completion.

Code that leverages this mechanism could look as follows. Delegating Session lifecycle management to SessionFactoryUtils allows Spring to detect a Session instance that is bound to an existing transaction via the current thread. Alternatively, use Spring's HibernateTemplate which automatically delegates to SessionFactoryUtils underneath.



Of course, the two data access operations can be in different methods, possibly in different data access objects. Typically, transactions will be demarcated at the business facade level, calling various DAO methods within. All of these calls will reuse the same Session instance within a transaction, without any additional effort by the application developer.

I agree that JTA's UserTransaction API is pretty simple, but Spring's PlatformTransactionManager isn't really harder: 3 methods there too - you just need to pass the TransactionStatus returned by getTransaction to commit/rollback. Spring also offers TransactionTemplate, allowing to implement a callback that automatically gets executed transactionally, and of course declarative transactions via AOP.

The difference is that PlatformTransactionManager uses a well-defined unchecked exception hierarchy, while UserTransaction throws various unrelated checked JTA exceptions. Take for example UserTransaction.commit: 4 unrelated checked exceptions plus 2 unchecked ones. That's why UserTransaction callers often resort to "catch(Exception)", rethrowing them as some ad-hoc RuntimeException.

Juergen

Well, I've just discovered more on spring's tx api (scarce docs). At the begining I thought that programatic transaction mgmt. could be done only with TransactionTemplate or AOP, but I see that JTA api can be completely replaced by spring's PlatformTM that even provides tx propagation (witch is non existent in JTA api at first hand AFAIK). So, I agree that spring's tx api is better.

10x again.

Regards,
Horia

P.S.
Your last code sample contains plain sf.openSession()/sess.close() calls mangled with SessionFactoryUtils.getSession(sf)/SessionFactoryUtils.closeSessionIfNecessary(session, sf). In my code, only the latter work with session reuse.


[/quote]

You're right, of course - my fault. The sample should have looked as follows:



Juergen