Hello,

I'm using hibernate 1.2.5 with weblogic 6.1 SP5. I'm using JTATransactionFactory as a tx factory. I've got a scenario in which I am saving an object from the web application (not within an EJB).

I start a transaction, then encounter an error when saving some objects to the database. My error handling code calls tx.rollback(). However, the transaction ends up being committed. I can see in my MSSQL profiler that an explicit COMMIT has been issued to the database.

If I use a JDBCTransactionFactory instead, then the transaction rolls back as expected.

Any ideas about how to debug this? I've enabled hibernate's logging, and can see the JTA transaction being started as a new transaction, and can see the rollback() issued successfully.

Thanks,
Dave

To reply to my own post, in my rollback handling, I had to add:

session.connection().rollback();

According to the docs, this is not required for a JTA transaction, but it 'fixed' my problem. However, in my SQL log, I see for my transaction a ROLLBACK, followed by a COMMIT. I am assuming that the line of code above as introduced the ROLLBACK, and the COMMIT remains from my original issue -- that is, why does a 'tx.rollback()' not result in the rollback of my JTA transaction?

Any insight would be appreciated.

Thanks,
Dave

Is the tx in "tx.rollback()" the hibernate transaction class? Or the UserTransaction class?

If you are using JTA transactions, you should not deal with hibernate transaction at all. Simply use the UserTransaction instance to demarcate your commits/rollbacks.

Hi Steve,

By tx I mean hibernate's JTATransaction, which wraps a UserTransaction. I don't start a UserTransaction myself, which perhaps is my issue.

Hibernate is configured to use JTATransactionFactory. When I start a transaction, I call:

Transaction tx = session.beginTransaction();

Hibernate returns a JTATransaction. What is nice (and I thought the whole point) about this, is that if there is no UserTransaction already running for this thread, then the JTATransaction constructor will create a new UserTransaction. Otherwise, the JTATransaction constructor will reference the existing UserTransaction.

So when my component is called from within a session bean, the JTATransaction references the container-started transaction. When my component is directly called from a web-app, the JTATransaction creates a new UserTransaction.

When I wish to rollback, I call:

tx.rollback();

If the JTATransaction started the UserTransaction, it calls UserTransaction.rollback(). Otherwise, the JTATransaction does calls UserTransaction.setRollbackOnly().

From the log4j logs, it appears that JTATransaction is calling ut.rollback(), but the transaction still gets committed.

Is my usage of JTATransactionFactory and JTATransaction correct?

Thanks,
Dave

Dave,

Is the JNDI DataSource you are using a transactional one, i.e. registered with the container's JTA? You need to set up a properly registered transactional DataSource with your container.

If the DataSource is transactional, it should automatically be notified of JTA commits and rollbacks. If not, and your symptoms indicate this, it would need its own "native" commit and rollbacks calls, as it is not aware of JTA at all.

Juergen

Hi Juergen,

My data source is a weblogic <JDBCTxDataSource> (defined in weblogic's config.xml) which is a transaction-enabled JDBC DataSource.

Dave

Juergen,

How do u ensure that a datasource is registered with JTA?

I have manually created a datasource using DBCP, and bound it to JNDI, and Hibernate is (mostly) successfully picking it up and using it, but when I do a commit on the UserTransaction that is handed to me via the SessionContext, the data fails to be committed (I can see the transaction is still open on the Sybase database, and any attempt to access the table being updated are locked by the as-yet-uncommitted update).

I presume this is because JTA does not know about the DataSource,and thus cannot commit it..

Thanks.

Colm

Depends. What JTA transaction manager are you using. Is this your app server transaction manager?

My "hibernate.properties" file has the following:



I'm on JBoss 3.2.2RC4 with Tomcat.

This seems to be picked up correctly, as I'm getting the following in the JBoss server.log

But that really does not matter to this discussion. Its more a matter of whether JBoss knows it is suppoed to control transaction for the given datasource with its transaction manager. The snippet you posted just shows that Hibernate is able to locate the transaction manager.

Ok.. in that case, I'll take a look at the J2EE packages to see if I can find a way to do this.

Setting up a transacted datasource is probably the most common action in a J2EE server. I'd be suprised if there is not docos on how to do this in JBoss.

We moved away from setting up the datasource in the app server (currently one of JBoss / Orion / Weblogic / Sun One) to setting the datasource up within the application itself (ultimately to be separated back out of the app, but still under our control, and via our ocde) for the simple reason that it gives us a homogenous method of setting up the datasource, regardless of what app-server / J2EE container we're on.. hence we're not at the mercy of the functionality (or lack of it) implemented in various containers.

If the XA option doesn't work out, we may have to revert to letting the container manage the datasource, but until then, I'd prefer to try to programatically get the datasource talking to JTA (or vice-versa, as the case may be).

Yeah, I don't think to many app servers support transacting datasource not under their control.

You might want to check out either JOTM or Tyrex for stand-alone stransaction managers, as that would really tie into what it sounds like you are trying to do in your project anyway. I have used Tyrex and have heard really good things about JOTM.

Another option for me would be to use Hibernates Transaction API (rather than the native JTA UserTransaction API), and point Hibernate at the in , which should cause Hibernate to go straight to a JDBC transaction (bypassing JTA transactions completely), and thus the fact that my datasource is not enlisted with the JTA Transaction Manager should not matter..

Using this method, I lose JTA transaction control, and I'm limited to having transactional control over the single JDBC datasource that I pass to Hibernate (via its JNDI name).

Am I missing anything??