File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes [JTA] Distributed transactions questions Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "[JTA] Distributed transactions questions" Watch "[JTA] Distributed transactions questions" New topic
Author

[JTA] Distributed transactions questions

Raf Szczypiorski
Ranch Hand

Joined: Aug 21, 2008
Posts: 383
Hi. I've been reading the JTA specs and also did some reading of the original OMG XA, DTP and TX specifications, and I get the idea of how this stuff works. However, I still have a few questions, any answers appreciated.

1. There are heuristic commits / rollbacks. How can this occur? I know of some that are caused by a long lag between a prepare() and commit() calls, what are the other possible causes? How often does that (heuristic desicion) happen?
2. When there are more than one resource managers (RM), and one has made a heuristic decision, and this cannot be checked if it was contrary to the whole transaction completion (for example, one resource manager decided to commit, whereas the whole transaction was rolled back), or indeed it was contrary - Java throws some HeuristicXXXExceptions, but what can be done afterwards to assure the state of the resources is consistent again? Or maybe nothing can be done? Basically the question is: how to recover from a heuristic decision made by one of the resource managers?
3. Suppose there are 3 RMs: A, B and C, and prepare() for all of them was successful, and then commit() was called and it worked fine for A, but failed for B (because there was network failure or sth) - what happens to C? I think it is committed anyways, and that B must have some log and during B's recovery it would commit the changes (the D in ACID), but network failure could be left unnoticed, and then commit() would never be called for B?
4. This one is closer to EJBs. Suppose I have developed an EJB on application server X, and I use a remote EJB deployed on server Y (for example, it has the MANDATORY transaction attribute, so that it must be called within a transaction, but doesn't create its own, throws exception instead). When the remote EJB is called, is the transaction context from X to Y somehow transferred? (similar question, not related to JTA: is the caller information - caller name, role - also transferred?) Do X and Y need to be the same type of servers to be able to talk (like Glassfish to Glassfish, JBoss to JBoss), or is it somehow standardised so that my Glassfish deployed EJB may call another remote JBoss deployed EJB?

Thank you.
Guy Pardon
Greenhorn

Joined: Jan 02, 2009
Posts: 2
Hi,

To answer your questions:

1 - Heuristics happen by a resource that is in-doubt and times out fatally. This should not happen often but it really depends on how available your subsystems are.

2 - Heuristic decisions are anomalies in the all-or-nothing (atomic) outcome of a transaction. There is no easy way to recover except for the HAZARD case - where it suffices to retry the commit/rollback until it succeeds. Other cases invariable require administrative intervention at the DBMS or the global application level. Some transaction managers like Atomikos (http://www.atomikos.com) allow the inclusion of application-specific log comments to aid in recovery of heuristics.

Note that heuristics are possible in ANY distributed system, even those that claim not to use "distributed transactions" for exactly that reason. This is a result of an impossibility theorem proved by Nancy Lynch et al.

To give you a simple example: many people use message queuing instead. In message queuing, heuristics occur in the form of messages moved to some "dead letter queue" because they fail to be delivered in time. With transaction managers like Atomikos, at least you have access to the global context when this happens. Without transactions, there is nothing to fall back to in order to aid in the resolution.

3 - For RM B, at least Atomikos would retry commit until it succeeds. This is a typical heuristic hazard case.

4 - Don't use EJB :-)

Again, heuristics are worst case scenarios. They can happen in all distributed data systems, but in transaction systems at least they are made explicit, managed, avoided if possible, and documented with the global transaction context if all else fails. In other (so-called non-two-phase-commit systems) they are simply ignored in the hope nothing bad will happen.

Best
Guy

Disclaimer: I work for Atomikos.
Raf Szczypiorski
Ranch Hand

Joined: Aug 21, 2008
Posts: 383
Thank you very much for your answers.
Could you elaborate on 4 a bit? I would like to know if transaction managers support (I don't know how to call this precisely) "transaction propagation to the client"? What I mean by this is that client A starts a transaction, bean B (different JVM, possibly different host and application server) which is called by A requires a transaction. Is the transaction started by A noticed by B? Does B know that it is actually invoked within a transaction, but it was started by the client? I think this is the part in OMG DTP spec that says about superior and subordinate nodes, where the client A run is superior node, and bean B is run in subordinate node. If this is possible (the propagation stuff), which transaction manager is then responsible for sending the prepare and commit / rollback messages?

Thanks.
Reza Rahman
author
Ranch Hand

Joined: Feb 01, 2005
Posts: 580
    
    5
Raf,

Sorry for the delay in answering this...just came back from vacation.

To answer #4 above, the entire EJB context, including transcations are remotely propagated. I'll have to double-check, but I do not think this can be done in a cross-vendor fashion, although I am not a 100% sure.

Best regards,
Reza


Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
Raf Szczypiorski
Ranch Hand

Joined: Aug 21, 2008
Posts: 383
Hi Reza,

from Java EE 5 specs:

Note that this transaction propagation requirement applies only to invocations
of enterprise beans in the same Java EE product instance1 as the invoking
component. Invocations of enterprise beans in another Java EE product
instance (for example, using the EJB interoperability protocol) need not prop-
agate the transaction context. See the EJB specification for details.

So it doesn't even have to be propagated from one instance to another instance of exactly the same type.
Couldn't find anything similar on caller / security context though.

Cheers.
Reza Rahman
author
Ranch Hand

Joined: Feb 01, 2005
Posts: 580
    
    5
Raf,

If memory serves me correctly, the last time I did this was with EJB 2.1 on WebSphere around 2001/2002. The transaction and security context remote propagation worked fine there.

It sounds from the spec text that cross vendor propagation isn't supported. I would not take the "product" verbage too seriously. I would bet the EJB remote protocol isn't reinvented from product-to-product for the same vendor :-).

Best regards,
Reza
Raf Szczypiorski
Ranch Hand

Joined: Aug 21, 2008
Posts: 383
This specification does not require the Product Provider to implement any particular
protocol for transaction interoperability across multiple Java EE products. Java EE
compatibility requires neither interoperability among identical Java EE products
from the same Product Provider, nor among heterogeneous Java EE products from
multiple Product Providers.
We recommend that Java EE Product Providers use the IIOP transaction
propagation protocol defined by OMG and described in the OTS specification
(and implemented by the Java Transaction Service), for transaction
interoperability when using the EJB interoperability protocol based on RMI-IIOP.
We plan to require the IIOP transaction propagation protocol as the EJB server
transaction interoperability protocol in a future release of this specification.


That settles it - not a must, but suggested, and possibly (JEE 6?) required in the future.

Raf
Guy Pardon
Greenhorn

Joined: Jan 02, 2009
Posts: 2
Raf Szczypiorski wrote:

That settles it - not a must, but suggested, and possibly (JEE 6?) required in the future.

Raf


Hi,

You can propagate transaction context across JVMs with Atomikos ExtremeTransactions - it works in any Java/Spring/Hibernate application.

Best
Guy
Ranganathan Kaliyur Mannar
Bartender

Joined: Oct 16, 2003
Posts: 1077
    
  10

Rumit Jain,
Your post was moved to a new topic.


Ranga.
SCJP 1.4, OCMJEA/SCEA 5.0.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: [JTA] Distributed transactions questions