Re: JTA Transaction query

From:

Owen Jacobson <angrybaldguy@gmail.com>

Newsgroups:

comp.lang.java.programmer

Date:

Fri, 13 Aug 2010 18:46:09 -0400

Message-ID:

<201008131846099462-angrybaldguy@gmailcom>

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 at
http://download.oracle.com/javaee/6/api/javax/transaction/UserTransaction.html#commit()
..

-o