• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

[JTA] Distributed transactions questions

 
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 383
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 580
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Raf Szczypiorski
Ranch Hand
Posts: 383
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 580
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 383
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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

 
Bartender
Posts: 1104
10
Netbeans IDE Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Rumit Jain,
Your post was moved to a new topic.
 
reply
    Bookmark Topic Watch Topic
  • New Topic