JTA Transaction query

G

gk

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 .

http://i218.photobucket.com/albums/cc298/curseofgoldendragon/programmatictransaction.png

Could you please clear this part.

Regards.
 
O

Owen Jacobson

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
 
G

gk

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

I thought the graphic link will be easy to understand by the people
because they were nicely formatted. I put the query on the side the
code concerned. I thought ,people can understand that very easily.

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

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 ?

I appreciate your time and post .
 
G

gk

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


Also, I'm doing this transaction in Weblogic 10 server . It has XA
support I know. What will happen in that case ? will there be a JDBC
rollback even there was a commit because of the entire transaction
fail ?
 
L

Lew

gk said:
I thought the graphic link will be easy to understand by the people

No one said it's not easy to understand. We say that it's
inconvenient to have to switch channels to maintain context and to
cite that to which we respond.
because they were nicely formatted. I put the query on the side the
code concerned. I thought ,people can understand that very easily.

It's not about understanding, it's about convenience. Make it
convenient for people to answer your questions, as Owen suggested.
Anyway , I'll try if this can be taken into texts otherwise.

Do you have a keyboard? If so, then you already have your answer and
you need spend no more time investigating - the material can indeed be
typed into a text format.
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 ?

There should be a rollback. Whether there actually will be a rollback
depends on the caveats in Owen's answer. There isn't enough
information in the magic-wand hand-waving ("// Carry out JMS
operations") in the example you provided to ensure that those
conditions are met, but clearly the book you cited intends that the
"operations" in question be XA compliant. To be on the safe side, you
should investigate your question with respect to actual library calls,
not textbook "// magic happens" comments.

You should follow Owen's advice to actually read the documentation for
the actual products you actually intend to actually use. Here on
Usenet we can point you to the path but we can't walk it for you.

For further understanding of your questions here and in the followup
post, use your favorite search engine and Wikipedia to look up "two-
phase commit". One of the fundamental skills we assume in Usenet is
the ability to look up further detail on key words and phrases you get
in answers here, and the willingness to do so.
 
L

Lew

Also, I'm doing this transaction in Weblogic 10 server . It has XA
support I know. What will happen in that case ? will there be a JDBC
rollback even there was a commit because of the entire transaction
fail ?
 
O

Owen Jacobson

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
 
G

gk

Thank you.


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...()

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 .
Technically , there should be a entire rollback because of the
transaction fail....but once a JDBC commit() executed in DB
operation , I never heard them to be rollback ...so here is the
confusion . What will happen now ?
 
G

gk

No one said it's not easy to understand.  We say that it's
inconvenient to have to switch channels to maintain context and to
cite that to which we respond.


It's not about understanding, it's about convenience.  Make it
convenient for people to answer your questions, as Owen suggested.


Do you have a keyboard?  If so, then you already have your answer and
you need spend no more time investigating - the material can indeed be
typed into a text format.


There should be a rollback.  

Do you mean the inner DB operations SUCCESSFUL JDBC commit be also
rollback ! ...thats very strange. I never heard a jdbc commit to
rollback.
 
O

Owen Jacobson

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.

-o
 
G

gk

You must not call connection.commit() on a JDBC connection, or any
other local transaction management methods, when using JTA.

Yup . I know that . I was thinking of a badly written code and was
thinking of a odd situation and was worried about its outcome .

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.

So, this means there will be a *JDBC commit* even though JTA
transaction fails .

This is what I wanted to know from the beginning . Thats the answer I
was looking for . I understand its a bad code and the outcome is a
partial upgrade.
 
R

Robert Klemme

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
 
O

Owen Jacobson

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top