Hibernate 3.0.5, JBoss 3.2.6

After reading this page,(http://hibernate.org/42.html), I have a few questions.

When implementing a session-per-request pattern in an BMT-EJB, why should I use "transaction demarcation with JTA" as opposed to "transaction demarcation with plain JDBC"? Will not using JTA have adverse effect on the datasource's manager, or something like that?

The page above says: "note that you should use JTA and a transaction-bound strategy in a JEE environment" and that "each Datasource you use in such a container is automatically handled by a JTA TransactionManager", but doesn't really say much else as to <b>why</b> you should use JTA trans over JDBC trans in JEE.

I have no problem using JTA, but I dont' want to use just because it's there. My persistence code only talks to one DB and is not distributed in any way. JTA seems like overkill. All I really need is the app server to pool the DB connections for Hibernate.

I ask, not to be difficult, but because I am doing this:

UserTransaction tx = (UserTransaction)new InitialContext()
.lookup("java:comp/UserTransaction");

like in the example, and became worried when I read this:

"For BMT beans, do not obtain the UserTransaction interface using a JNDI lookup. Doing this violates the EJB specification, and the returned UserTransaction object does not have the hooks the EJB container needs to make important checks."
(http://docs.jboss.com/jbossas/admindeve ... chapt.html)

Now I'm thinking maybe JDBC Tx would be safer.

Basically I need to decide which is worse, not using JTA in a BMT-EJB, or looking up the UserTransaction in a way that violate the EJB spec.

Any offerings of insight would be greatly appreciated.

Interesting matter.

I'm almost in the same situation, using a J2EE container (JBoss) which provides JTA support, but not using EJB.

So, following Hibernate's ref., I should use JTA - UserTransaction obtained in the BMT-bean via JNDI lookup.

But it looks like this violates EJB specifications.

And by the way, it seems that getCurrentSession() only binds to the current JTA tx and doesn't begin one itself if any exists, which is a bit different to Session binding to threads, which is automatic. So you have to obtain the UserTransaction, do a tx.begin(), and then getCurrentSession() works.

I guess the best way to use JTA is in a CMT environment, probably.

I feel that documentation is not very clear on this issue, if you have any clarification, example or doc I would be very interested.

Thanks,

Giulio

If you need JDBC to demarcate transactions and to avoid 2PC then you can use thread local sessions ( JTA transactions are thread local and it is safe to use thread local sessions with JTA too "The UserTransaction.begin method starts a global transaction and associates the
transaction with the calling thread" ).
Hibernate implements both strategies :
http://www.hibernate.org/hib_docs/v3/re ... nt-session

Thanks for the reply, Baliukas.

Yes, I knew that JTA transaction are thread local, I wasn't questioning if they were safe or not in a concurrent environment.

I always used the "thread local" pattern, first with a HibernateUtil helper and then with Hibernate 3.1 getCurrentSession() implementation which binds sessions to threads.

I just wonder if it's correct to use JTA without CMT, because you're forced to begin manually transactions looking up UserTransaction in JNDI and that's not recommended in JBoss documentation.

In my main application I'm using, right now, JTA as suggested in Hibernate ref doc without CMT. I'm eagerly awaiting for EJB3 to become final and implement it with Hibernate.

Giulio

BTW it is safe to use UserTransaction with BMT too:

"The code sample below illustrates the usage of UserTransaction by a
TX_BEAN_MANAGED EJB session bean:
// In the session bean’s setSessionContext method,
// store the bean context in an instance variable
SessionContext ctx = sessionContext;
..
Java Transaction API
// somewhere else in the bean’s business logic
UserTransaction utx = ctx.getUserTransaction();
// start a transaction
utx.begin();
.. do work
// commit the work
utx.commit();
"
JTA Specification

It is perfectly correct.

It is *even better* to use CMT, where possible.

Yes, it is safe, and as stated in Hibernate's ref doc you can avoid using Hibernate Transaction API this way.

So back to the original question, I still think that the best transaction demarcation strategies are

- in an unmanaged environment, JDBC tx with Hibernate thread local pattern and Transaction API;
- in a managed environment, JTA with CMT.

I feel that JTA with BMT is a sort of "compromise". I think a good reason to use that pattern is that EJB2 is very verbose in defining transaction boundaries. EJB3 should really make that a breeze, with annotations.


Giulio

In my view, JTA should be used even outside of Java EE, using a standalone JTA implementation like in Seam or JBoss Microcontainer.

The proliferation of JTAish transaction management APIs in Java needs to stop before it gets totally, totally out of hand.

I agree with you, Gavin.

For "unmanaged environments" I intended very small (web) applications, meant to run in Tomcat (like the one the original poster was talking about).

I can't think of a serious application which shouldn't use a strong J2EE application server like JBoss, so nearly 95% of those applications should use standard specifications like JTA.

Hibernate 3.1 offers the "thread" current session context pattern which is great for the other 5% of trivial applications.

Giulio

Right, jboss mc or seam can be used for "very small (web) applications" if you like.

Thanks for the input and discussion. It was very informative.

However, for my situation I don't see any quick fixes here.

I need to use BMT, CMT won't work. The code beneath my bean is not "all or nothing".

My persistence code is, architectually, a few layers away from the Bean and does not have access to the Bean's Context. Refactoring to have it passed all the way down as a parameter would be a major change.

It looks like org.hibernate.context.ThreadLocalSessionContext would be helpful, but that would require upgrading the project to Hibernate 3.1. Something we did not plan on doing.

Therefore, I don't think there will be an easy way for me to properly use JTA here.

With BMT, can I just stick to using plain Hibernate's Sessions & Transactions, void of any JTA Transaction?

Would that roughly be equivalent to simply using ThreadLocalSessionContext as the CurrentSessionContext?

With BMT, it is totally up to you. You can choose to use JTA or to use strictly JDBC-based transactions.

There is nothing roughly equivalent to ThreadLocalSessionContext. Have a look at that monster ;) The typical pre-3.1 approach was to use and manage a ThreadLocal yourself within your application code.