9 Replies Latest reply: Aug 22, 2011 8:11 AM by Jonathan Halliday RSS

Transaction propagation across two jboss servers

tomasza Newbie

Hello everyone,

Can you please explain to me how does transaction propagation works across two the same JBOSS instances. I have read article http://community.jboss.org/wiki/TransactionPropagationWithJBoss, but am interested in scenario 2 (according to this article's numeration) which is omitted in a description.

As far as I understand the JTA specification there can be only one level of TransactionManagers and if we want to have transaction we need some way of comunication between them. In above article I read that one way to comunicate between them is Corba but it is rather heavy and as I understand it is used in heterogenous (different AS) environments. But what happens if we have two the same jbosses sharing a transaction? Is there only one transaction manager for a transaction (i.e. on a jboss on which the transaction was started) or do managers communicate or maybe nest in some way?

 

Regards,

Tomek

  • 1. Re: Transaction propagation across two jboss servers
    Michael Musgrove Master

    I hear what you are saying about CORBA being rather heavy but:

     

    - from a performance point of view I don't think CORBA is nessarily less efficient than JRMP. Do you have a use case where performance is critical. There are many areas in an application where performance can be improved and transaction propagation is probably low down on that list;

    - from a configuration point of view the switch over from JTA to JTS is trivial (we include a simple ant script in the distribution to copy over the relevant jar files).

     

    So, you asked how does it work when making calls between EJBs on two similar JBoss applications servers. The only way to answer this question is to go under the hood (and consult the JTS specificaton at http://www.oracle.com/technetwork/java/javaee/tech/jts-140022.html), so I am not sure what kind of answer you are looking for, but ... in brief the answer is:

     

    EJB 1 invokes a remote EJB 2. The server (call it server 1) hosting EJB 1 encodes the transaction (context) using (CORBA) IIOP and the server (server 2) receiving the request decodes it and associates it with the thread that it uses to invoke EJB 2. If EJB 2 uses the services of, for example, a datasource then the transaction manager running in AS 2 automatically enlists the datasource into the transaction (with the transaction manager running on server 1). When the transaction is committed at server 1 (or at the client) the transaction manager running on server 1 knows that it should tell the datasource (used by EJB2) to commit any work it did (and it does so using CORBA invocations). But I suspect this wasn't the kind of answer you are looking for?

  • 2. Re: Transaction propagation across two jboss servers
    tomasza Newbie

    Thank you for you reply.

    Actually it was precisely the answer I wanted The case that I'm trying to resolve is not directly connected to this question but  I wanted to have some understanding of the technology.

    In my project i'm trying to create transaction which runs across jboss and distributed spring application (with mahalo transaction manager). Standard configuration of transactions doesn't work and I'm wondering if it is possible to connect jboss tm and mahalo in some way. For what I understand now it is not possible because we couldn't demand that other transaction managers will implement jts specification and even if they do the transaction context encoding can be different. In this situation I don't have idea how can I resolve this problem.

     

    On the other hand I'm still curious about what you have written. As far as I understood this there is one main transaction manager (on the AS who started the transaction) and other transaction managers are it's helpers who enlist their resources in the transaction's context. If this is case than I don't get the idea of copying transaction context to every "helper" tm because it leads to situation when we have many copies of context which need synchronization and I can't imagine how whole system behaves on commit. I have read jts and ots specifications but the first one is very generic and the second one is vague and unfortunaly there are not much help for me.

  • 3. Re: Transaction propagation across two jboss servers
    Michael Musgrove Master

    In my project i'm trying to create transaction which runs across jboss and distributed spring application (with mahalo transaction manager). Standard configuration of transactions doesn't work and I'm wondering if it is possible to connect jboss tm and mahalo in some way. For what I understand now it is not possible because we couldn't demand that other transaction managers will implement jts specification and even if they do the transaction context encoding can be different. In this situation I don't have idea how can I resolve this problem.

    Since JTS is the only supported mechanism you would need to write something that interposes itself between the mahalo and JBoss TMs. The component would register JBoss TM as a transaction participant using CORBA. When the transaction gets committed that component would be asked to prepare and commit at which point you could "do the right things" to drive mahalo.

     

    We also provide an HTTP interface to our TM (for both clients and transaction participants) if you cannot drive things using CORBA.

     

    On the other hand I'm still curious about what you have written. As far as I understood this there is one main transaction manager (on the AS who started the transaction) and other transaction managers are it's helpers who enlist their resources in the transaction's context. If this is case than I don't get the idea of copying transaction context to every "helper" tm because it leads to situation when we have many copies of context which need synchronization and I can't imagine how whole system behaves on commit. I have read jts and ots specifications but the first one is very generic and the second one is vague and unfortunaly there are not much help for me.

    Any work on resources  performed by the second AS enlists the resource with the TM running in the first TM (using OTS/CORBA invocations). When the transaction is committed the TM in the 1st AS knows where all the resources are and drives them independantly of the TM running in the 2nd AS (ie there is no issue about "context synchronisation").

  • 4. Re: Transaction propagation across two jboss servers
    tomasza Newbie

    Since JTS is the only supported mechanism you would need to write something that interposes itself between the mahalo and JBoss TMs. The component would register JBoss TM as a transaction participant using CORBA. When the transaction gets committed that component would be asked to prepare and commit at which point you could "do the right things" to drive mahalo.

    We are thinkink of similiar solution but in our situation it would be better for us if the JBoss was the main transaction manager. We found that mahalo transaction manager implementation that we use can be used as XAResource and we are thinking of enlisting whole distributed spring application as one XAResource, but now we have a problem with integrating such custom XAResource with JBoss. Is it possible to enlist such XAResource in JBoss transaction (preferably container managed)?

  • 5. Re: Transaction propagation across two jboss servers
    Jonathan Halliday Master

    transactionManager.getTransaction().enlistResource(...)

     

    The tricky bit is getting a handle on the transaction manger, particularly in a CMT environment. It is doable if you're willing to step outside of the JEE specs though.

     

    Not sure how enlisting a resource is going to help you though - you still have to implement it and that is going to be tricky. Think through how you expect to implement prepare() and  recover() in particular. Last time I looked at river it didn't support subordinate transactions so IMO you'd need to fork and extend it quite a bit for this use case.

  • 6. Re: Transaction propagation across two jboss servers
    tomasza Newbie

    Not sure how enlisting a resource is going to help you though - you still have to implement it and that is going to be tricky. Think through how you expect to implement prepare() and  recover() in particular. Last time I looked at river it didn't support subordinate transactions so IMO you'd need to fork and extend it quite a bit for this use case.

    I found mahalo implementation which can be used as XAResource so I don't need to write it myself. It is a part of distributed spring environment which I use.

    The tricky bit is getting a handle on the transaction manger, particularly in a CMT environment. It is doable if you're willing to step outside of the JEE specs though.

    Can you tell me how to do it?

  • 7. Re: Transaction propagation across two jboss servers
    Jonathan Halliday Master

    hmm, interesting. link please.

     

    The trickery required depends on exactly which version of the server you have, but com.arjuna.ats.jta.TransactionManager.transactionManager() is probably a good place to start.

  • 8. Re: Transaction propagation across two jboss servers
    tomasza Newbie

    This is the manager implementation:

    http://www.gigaspaces.com/docs/JavaDoc8.0/com/sun/jini/mahalo/TxnManagerImpl.html

    And this is the XAResource adapter:

    http://www.gigaspaces.com/docs/JavaDoc8.0/com/j_spaces/core/client/XAResourceImpl.html

     

    As I understand I must use object obtained from com.arjuna.ats.jta.TransactionManager.transactionManager() to enlist this XAResource at the begining of a method which uses it and it will work even if the transaction is managed by the container and i.e. it wasn't started in this method? We use JBoss 5.1.0.

  • 9. Re: Transaction propagation across two jboss servers
    Jonathan Halliday Master

    Ahh, ok, so a proprietary vendor already did the fork and enhancements you need . Well if you're locked into their platform anyhow then it makes sense to leverage those addons. Gook luck with it. Don't forget to test crash recovery.