6 Replies Latest reply: Feb 9, 2005 3:51 AM by Jesus Alberto Paz Jimenez RSS

Transactions Across Multiple Servers

Ivan O. Parra Novice

 

"ioparra" wrote:
"ioparra" wrote:
"ioparra" wrote:
Can someone explain the expected functionality for Transactions across multiple Jboss instances.

For example if I have a client who access Server "A" and this server access Server "B"(requires transaction) in the same transaction, how many transactions are created? Are the transactions shared?

From my experience, I would see the TM of server A start a transaction with some XID then call Server "B". Server "B" would then start a different XID and do its work. Is this the correct assumption? If so, is there any way to pass the XID to Server "B" so that its committable resources share the same transaction? How are commits handled if Server "A" is the source of the commit call? Can the commit be expected to propagate to Server "B"? What happens if Server "B" uses resources that Server "A" does not?

I'm assuming XA only of course. I would test this myself but I don't have an XA driver readily available. Even then, I only have a single XA resource, this problem becomes more complicated with more XA resources. I can this as being a clustering nightmare waiting to happen.

I know this problem is easily solved by using local interfaces. I'm just curious to see the possible responses.

-Ivan


  • 1. Re: Transactions Across Multiple Servers
    jhalli Newbie

     

    "jhalli" wrote:
    "jhalli" wrote:
    "jhalli" wrote:
    Hello Ivan

    I'm not sure about JBoss, but the Arjuna+JBoss product ( http://www.arjuna.com/products/jboss) addresses this requirement.

    The free 30 evaluation version of the product comes with a demo app that involves a client application accessing EJBs in two JBoss instances within the same global transaction.

    The infrastructure takes care of propagating the transaction context between client and servers and ensuring that any xa resources which may be needed e.g. the two databases used for EJB state, are enrolled in the same global transaction. You get reliable distributed 2PC and automatic crash recovery without any significant programming effort.

    Regards

    Jonathan Halliday
    Arjuna Technologies.
    http://www.arjuna.com


  • 2. Re: Transactions Across Multiple Servers
    kstogian Newbie

     

    "kstogian" wrote:
    "kstogian" wrote:
    "kstogian" wrote:
    "kstogian" wrote:
    "kstogian" wrote:
    Hello Ivan,

    could you elaborate more on how your problem is solved with local interfaces.

    Thanks Kleandros.


  • 3. Re: Transactions Across Multiple Servers
    Ivan O. Parra Novice

     

    "ioparra" wrote:
    "ioparra" wrote:
    Well, the problem that I pose requires 2+ seperate VMs. To have these VMs communicate to each other, a remote interface must be exposed. This creates a Transaction Management issue that Arjuna + JBoss handles(via XATransactions and such). Somewhere, there must be a Omniscient Transaction Manager handling all possible combinations of Resources and which transaction is using which resources(via XID and XAResource).

    Forcing Local Interfaces means that Server "A" can never call Server "B", it can only call on resources that Server "A" provides. If the resources on Server "B" were exposed on Server "A" (either remote or local), Server "A" would be complete. The Jboss TM can handle the 1 VM problem.

    It can work with both remote/local on the same server. But if the decision is to cluster/HA the previous 1 VM environment and the environment is designed to use remote interface... You'll have the scenario I mentioned before. You'll need a more complex TM to handle the Transaction state of this complex system.

    -Ivan

    Correct me if I'm wrong.


  • 4. Re: Transactions Across Multiple Servers
    Danilo Conde Newbie

    Hi Ivan,

    > From my experience, I would see the TM of server A start a transaction with some XID then call Server "B". Server "B" would then start a different XID and do its work. Is this the correct assumption?

    You're right. This is what Jboss's transaction manager does. It does not propagate transactional context. As server "B" receives a request without transactional context, it starts a new transaction, completely independent of server "A"'s one.

    > If so, is there any way to pass the XID to Server "B" so that its committable resources share the same transaction?

    Yes, but not using the default TM as it is. You would have to modify it or use a third party implementation (Arjuna, for example, as mentioned in the other reply).

    > How are commits handled if Server "A" is the source of the commit call? Can the commit be expected to propagate to Server "B"? What happens if Server "B" uses resources that Server "A" does not?

    Well, as there will be two distinct transactions, each one will do 2PC with its own resources. And no commits will be propagated.

    I hope I've helped. Feel free to contact me if you have any questions...

    Danilo


  • 5. Re: Transactions Across Multiple Servers
    Bill Burke Master

    Just curious. Why do you need distributed transactions? Even if JBoss supported distributed transaction propagation, IT SHOULD BE AVOIDED AT ALL COST. DTP is extremely slow no matter whose implementation you use, you will also have a VERY hard time debugging concurrency issues.

  • 6. Re: Transactions Across Multiple Servers
    Jesus Alberto Paz Jimenez Newbie

    Sorry, but I'm a bit amazed. If you think that distributed transaction
    propagation should be avoided at all cost, why Jboss supports it by way of TransactionPropagationContextFactory and TransactionPropagationContextImporter interfaces?.
    I think, though it is really costly there are situations in which it will be useful. such as when you are working with an existing server and you can't deploy your application in the same server.
    I suppose you can use web services and ws-transaction to control the whole process, but I think it will be slowly.
    Just curious, what solution do you suggest when have to work in a situation like that described by Ivan?.
    I agree with you in that TPC is costly. By example, I'm working in its implementation for the integration of Jboss and Jotm and It will be necessary to propagate the transaction context back to the caller JVM for the registration of global coordinator.