Re: JTA Transaction query

From:

Robert Klemme <shortcutter@googlemail.com>

Newsgroups:

comp.lang.java.programmer

Date:

Sat, 14 Aug 2010 14:19:23 +0200

Message-ID:

<8cnfufFc87U3@mid.individual.net>

On 14.08.2010 06:05, Owen Jacobson wrote:

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:

On Aug 13, 6:44 pm, Owen Jacobson <angrybald...@gmail.com> wrote:

On 2010-08-13 08:37:38 -0400, gk said:

Here I have a query in simple JTA Transaction . I am reading from
the book "Beginning Spring Framework 2" By Thomas Van De Velde,
Bruce Snyder, Christian Dupuis, Sing Li, Anne Horton .

There is one section where I'm confused . I have written my query
along side the code. Please have a look at this book excerpt . This
is a google book graphic print .

Can you please stop doing this? Transcribing the code in question will
make it much easier for people to answer your questions. Since you're
getting answers for free, it's in your interest to make it easy.

As for your question: when multiple transactional resources are in use
in a single JTA transaction (for example, when you're working with a
database and a message broker), JTA uses something called XA* to
coordinate commits and rollbacks. XA specifies a two-phase commit
mechanism that ensures that all transactional resources will commit a
transaction ("prepare" phase) before actually committing the
transaction ("commit" phase).

As a result, the resources you're using in your transaction must
support XA transactions. Most transaction-capable systems do
support it
(XA is widely used in enterprise apps), but there are a few that
don't.
Attempting to use non-XA resources in an XA transaction will fail
early
(and abort the transaction) rather than risking inconsistencies. Read
the documentation for your transactional services (JDBC drivers,
message brokers, JCA connectors, and so on) for information on how to
set them up for XA transactions.

Some JTA implementations support adding a single non-XA resource into
an XA transaction; there is an implementation for this that is
transactionally safe provided no heuristic recovery has to happen.
Read
the manual for your transaction manager (usually, part of your EE
container) for details.

-o

*http://en.wikipedia.org/wiki/X/Open_XA

Anyway , I'll try if this can be taken into texts otherwise.

Thank you.

Thanks for your time . By the way, I became more confused after
reading your post. My questions was very straightforward. What will be
the outcome of that code ? If I code that way , will there be a
rollback or not ?

If your database server is set up correctly, and
if your database driver is set up correctly, and
if your message broker is set up correctly, and
if your transaction manager is set up correctly, and
if the specifics of your program allow for it, then
either both the database and the message operation will commit, or both
the database and the message operation will roll back
If the JTA provider has decided that a transaction cannot be committed
(say, because one of your messaging operations fails and invalidates
the transaction), then the call to userTransaction.commit() will raise
an exception, as documented
athttp://download.oracle.com/javaee/6/api/javax/transaction/UserTransac...()

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'd say this is heavily container specific: JBoss wraps JDBC Connection,
Statement and the like anyway so they could simply make the wrapper
throw from commit() if the connection was used as part of a JTA TX.
Clarification can only be obtained through reading the docs and probably
also testing this with the specific version of the container.

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/