Re: XA transactions and autocommit

Allan Saddi wrote:
>
> I've been playing around with JTA using Apache Geronimo and the
> postgresql-8.1-407.jdbc3.jar driver. I've noticed a minor problem. The
> driver's XA code disables autocommit and assumes it will remain so
> indefinitely. tranql-connection (used by Geronimo for pooling) enables
> autocommit whenever the connection is returned to the pool.
> (Specifically in its ManagedXAConnection.cleanup method.) According to
> the J2EE Connector spec, this is apparently the correct thing to do.

Specifically, the spec says that:

A resource adapter must manage the auto-commit mode as follows:
* A transactional resource adapter, either at XATransaction or
LocalTransaction level, must set the auto-commit mode to false within

transaction, either local or XA, on a connection participating in the
transaction.
This requirement holds for both container-managed and bean-managed
transaction demarcation.
* A transactional resource adapter must set the auto-commit mode to
true, on connections that are used outside a transaction.

What's the resource adapter in this scenario? Is it the PostgreSQL JDBC
driver or TranQL? If it's TranQL, then it's not properly calling
setAutoCommit(false) when the connection is used in a global
transaction. If it's the JDBC driver, then we're not doing our job
properly, but then TranQL shouldn't be messing with setAutoCommit in the
first place.

> I didn't notice the problem until I tried rolling back a transaction,
> where I discovered it was being committed instead. Eventually I traced
> it to the fact that autocommit was on.
>
> Arguably, if you follow what the connector spec has to say about
> autocommit and XA transactions, autocommit should be on by default and
> should only be explicitly disabled during the duration of a transaction.

Yeah, I agree that's what we should do. Even if the spec isn't 100%
clear on this, it looks like the safest thing to do. Furthermore, we
should probably throw an exception if you try to set auto commit to true
within a global transaction.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com