Re: JTA Transaction query
On 2010-08-15 20:28:56 -0400, Lee Fesperman said:
"Owen Jacobson" <angrybaldguy@gmail.com> wrote in message
news:2010081400053212891-angrybaldguy@gmailcom...
On 2010-08-13 23:37:24 -0400, gk said:
On Aug 14, 3:46 am, Owen Jacobson <angrybald...@gmail.com> wrote:
On 2010-08-13 13:08:37 -0400, gk said:
I
understand that part . call to userTransaction.commit() will raise
an exception but does that rollback the successful JDBC explicit
commit() in my DB operation ? This is what I wanted to know .
You must not call connection.commit() on a JDBC connection, or any
other local transaction management methods, when using JTA. The commit
method on a JDBC connection is used only for transactions managed
entirely by the database. JTA transactions must be committed through
the transaction manager, which means using userTransaction.commit() (or
declarative transaction management).
I *believe* that calling commit on the JDBC connection will detach the
JDBC connection from any JTA transactions and commit it immediately,
separated from JTA transaction management. However, if you really want
to know, write up a test case or read the JTA spec.
I couldn't find anything in the JTA spec about issuing a 'local'
database commit within a global (XA) transaction, though it does state
that it is allowable to mix global (XA) transactions and local
(database) transactions in the same connection provided each
transaction (of either type) is completed before another is started.
I'll bow to your expertise on this one; I've never had to implement
anything that coordinates with JTA beyond some proof-of-concept JCA
examples. Mixing resource-local transactions and JTA transactions seems
like an obvious "don't do that, then" situation to me - I'd rather
spend effort fixing the code than spend effort trying to understand the
rules around how the broken code "should" behave.
However, the XA spec (under "The Application Program (Native)
Interface") requires that a SQL RDBMS not allow the global transaction
(while active) to be affected by SQL syntax (e.g. COMMIT WORK and
ROLLBACK WORK) or API services (e.g. commit() and rollback() in
java.sql.Connection).
So it seems that a SQL RDBMS that allows a local commit to detach the
transaction from JTA is not properly implementing global (XA)
transactions.
Compounding this is the structure of the JTA APIs. As there's no
client-facing enrollment API for adding resources to a JTA transaction
in most Java EE components, resources are automatically enrolled in
ways that aren't always obvious to newcomers.
We (see my sig) simply throw a SQLException when any kind of local
commit/rollback is attempted while the connection is participating in a
global transaction.
That seems sensible too.
We also disable auto-commit during the lifetime of a global transaction.
I would expect this to be required by JTA.
Thanks for the insight,
-o