Author: Mark Little
Date: 11-19-04 16:27
> I'm trying to implement the following situation: two
> applications sitting in two different JVMs on distinct machines
> (accessible by HTTP, IPs are known in advance) want to
> participate in a transaction that one of them starts. That is,
> each application wants to enlist a XAResource (not necessarily
> database) in such a manner that when the initiator calls
> commit, the XAResource in the JVM of the joined application
> commits as well as the XAResource of the initiator.
> As far as my understanding goes this must be done with
> explicit propagation, JNDI, or both - but I don't find anything
> related to in in documentation, forums or examples.
For a start what you need to do is propagate the transaction context from the originator to the destination. But that isn't the whole story, because you then need to use this context to register your XAResource with the transaction. Now, if we take the simplistic case where interposition is not used (a subordinate coordinator is not created to reside in the same VM as your remote XAResource), then you will be registering your XAResource back with a remote coordinator. Unfortunately, XAResources aren't directly remotely invocable - you'd have to put some work in to do that.
So, the easiest solution would be to use interposition. A subordinate (proxy) coordinator is created in the same VM as the XAResource, you register your XAResource with that, and the subordinate is registered remotely with the originating transaction coordinator. Obviously this interposed coordinator must be remotely invocable.
This is a round about way of saying that just propagating the context alone isn't going to help you. You need support from the transaction service to make your life easy. You need a transaction service that supports distributed transaction. Otherwise, you'll have to do a lot of work (and I haven't even begun to consider what you would have to do in the event of failure if you did this all yourself.)
Fortunately for you, ATS gives you all of this.
> Can somebody give me a hint how to accomplish it? Do I have
> to work with an ORB explicitly?
You need to use the ORB to accomplish this. By default we run with JacORB and if your services are CORBA objects, then the context can be propagated automatically. If they aren't, then you need to use RMI-over-IIOP, and in which case, the context is again passed implicitly for you. Either way the ORB is utilized in this scenario, but you don't need to be aware of this. You still work at the level of the JTA in both JVMs, and the fact that the JTS is running underneath isn't visible to you.
If you want to use explicit context propagation, then you can but you will be working at the level of the JTS as well as the JTA.
Date: 11-23-04 19:16
Thanks a lot, Mark!
Now concerning ORB, which I'm familiar with only at theoretical level: you write that "they will need to use RMI-over-IIOP" when I decide work with implicit propagation. What exactly needs to be done, what has to be remotely callable? What is the internal (transparent to me) mechanism of transporting TA context, and to which extent is RMI-over-IIOP identical to JNDI lookup?
Author: Kevin Conner
Date: 12-14-04 12:40
Sorry for taking so long to answer this question.
There are two options for implicit context propogation, both of which are based on the IIOP transport layer. Using CORBA server/client and using RMI server/client.
The IIOP transport layer is native to CORBA and is also an alternative transport protocol that is supported by RMI, the RMI native protocol being JRMP.
The original suggestion was to use IIOP (or RMI/IIOP) to take advantage of the HTTP tunneling provided by the ORB, thus allowing you to transarently pass the transaction context over your network. I put together a simple example of using RMI/IIOP but, unfortunately, then discovered that JacORB no longer supports tunneling of IIOP over HTTP. JacORB does provide a proxy that can be used instead but proxies IIOP instead of tunneling over HTTP.
Can you tell us more about the restrictions at your transport level?
Date: 12-29-04 20:12
thanks for your answer and apologies for vacation-caused delay.
Theoretically, I can send only strings, but as I learned they can represent results of a object_to_string ORB call. I would rather not rely on HTTP being allowed.
Could you send me your example so I can try to learn from it and possibly use Arjuna with another ORB instead of JacORB? If you feel I missed an important point in the docs please point me to it.
How do I "bind" the subordinate coordinator to the main one? They communicate transparently to me, but could I try manage this communication myself or does it group remote method invocations together, prohibiting any manual modification?
Thanks and happy New Year!
Author: Kevin Conner
Date: 01-05-05 09:28
> Theoretically, I can send only strings, but as I learned they
> can represent results of a object_to_string ORB call. I would
> rather not rely on HTTP being allowed.
Can you elaborate a bit more on the restrictions? Is your only transport HTTP? If so, what is restricting you to using strings?
> Could you send me your example so I can try to learn from it
> and possibly use Arjuna with another ORB instead of JacORB? If
> you feel I missed an important point in the docs please point
> me to it.
The only ORB we support at present is JacORB, we can't guarantee that another ORB would work without qualifying it. I can send you the example but it only shows RMI integration over IIOP.
> How do I "bind" the subordinate coordinator to the main one?
> They communicate transparently to me, but could I try manage
> this communication myself or does it group remote method
> invocations together, prohibiting any manual modification?
The protocol involves a number of messages sent over IIOP, both in the registration of the participants/subordinate coordinator and in the progression of the specific protocol (2PC). It is a non trivial task to implement the interposition required.
Happy New Year.
Date: 03-17-05 16:39
thanks for your previous reply.
Over the last two months, my scenario has changed. The situation is that
- components communicate through asynchronous (non-JMS) messages
- it is possible to send Java Objects as contents of this messages
- the components do not provide RMI functionality but the firewalls engaged may be configured to allow communication of transaction managers for executing the RMI calls
- it is possible to set up an ORB but the setup effort should be minimized; it would be great if not manual installation would be needed.
Does the example you offered work under these circumstances? Even if not, I would be interested what I have to set up to make it work.
Furthermore, I don't yet understand whether the propagated context makes the interposed TM know where the origination TM resides.
A rather basic question is which JTA entities can be bound to JNDI: UserTransaction yes, but what about XAResource/XADataSource und what about the Transaction (i.e., the specific TS class that implements it). Am I right in thinking that the association of a thread with a JTA Transaction interface is such that it is not possible to simply enlist a XAResource in it which is used by another thread, even if the usage occurs over the Arjuna-provided JDBC driver layer?
Enough questions for today.
Author: Mark Little
Date: 03-28-05 10:34
> Hello Kevin,
Hi Michael. Kevin is on vacation, so I'll reply.
> thanks for your previous reply.
> Over the last two months, my scenario has changed. The
> situation is that
> - components communicate through asynchronous (non-JMS)
> - it is possible to send Java Objects as contents of this
> - the components do not provide RMI functionality but the
> firewalls engaged may be configured to allow communication of
> transaction managers for executing the RMI calls
> - it is possible to set up an ORB but the setup effort should
> be minimized; it would be great if not manual installation
> would be needed.
> Does the example you offered work under these circumstances?
Yes, Kevin's suggestion would still work here. However, if RMI or the ORB doesn't sit naturally in your new architecture, there are other ways within ATS to propagate the context - the ATS product is not tied to IIOP or JRMP, they are just the normal ways in which our users work.
> Even if not, I would be interested what I have to set up to
> make it work.
> Furthermore, I don't yet understand whether the propagated
> context makes the interposed TM know where the origination TM
That's part of the basic transaction protocol and defined within the context that is propagated from importer to importee.
Your basic scenario sounds similar to others we've encountered over the years and even if there are subtle differences, we've experience in working with our customers to tailor fit solutions. I'd encourage you to get in touch with us directly about becoming a customer, as there's much more we can do for you through that route.
> A rather basic question is which JTA entities can be bound to
> JNDI: UserTransaction yes, but what about
> XAResource/XADataSource und what about the Transaction (i.e.,
> the specific TS class that implements it).
You typically locate XADataSources via JNDI. XAResources, since they eventually come from XADataSource (via XAConnection) don't need it.
> Am I right in
> thinking that the association of a thread with a JTA
> Transaction interface is such that it is not possible to simply
> enlist a XAResource in it which is used by another thread, even
> if the usage occurs over the Arjuna-provided JDBC driver
No, it's possible for one thread to enlist a resource with a transaction that represents a connection being used by another thread.
> Enough questions for today.
> Many thanks,