Keeping track of global Xid-local Xid mappings part two

[rookie1977]

This is my last question I promise, and thank you for help in advance.

Scenario:
I have server side system using XA capable RDBMS with XA capable JDBC driver and I want to expose my services as CORBA services to participate in distributed transaction using JBoss JTS/OTS.

Can I transparently expose my underlying JDBC XAResource object to be part of the global transaction via JTA/OTS, or do I have to code it (keep track of global Xid-local Xid mappings).

Do I have to implement ResourcePOA class, and then to perform following code with my implementation:
Resource corbaReference = org.omg.CosTransactions.ResourceHelper.narrow(OA.getRootOA(
ORB.getInstance("ServerSide")).corbaReference(myImplementation));

RecoveryCoordinator recoveryCoordinator = OTSManager.get_current().get_control().get_coordinator()
.register_resource(corbaReference);

Or can I somehow tell JTS/OTS transaction manager that my underlying JDBC XAResource implementation is the actual object I want to use.

The problem is that ResourcePOA methods' signatures dont have Xid argument, but rather transaction manager implicitly inserts Xid of the transaction in question.

[marklittle]

"rookie1977" wrote:
This is my last question I promise, and thank you for help in advance.

If you have problems, just keep posting. We can only ever promise best-effort help on the forums, but hopefully that will be enough.

Scenario:
I have server side system using XA capable RDBMS with XA capable JDBC driver and I want to expose my services as CORBA services to participate in distributed transaction using JBoss JTS/OTS.

Can I transparently expose my underlying JDBC XAResource object to be part of the global transaction via JTA/OTS, or do I have to code it (keep track of global Xid-local Xid mappings).

Do I have to implement ResourcePOA class, and then to perform following code with my implementation:
Resource corbaReference = org.omg.CosTransactions.ResourceHelper.narrow(OA.getRootOA(
ORB.getInstance("ServerSide")).corbaReference(myImplementation));

RecoveryCoordinator recoveryCoordinator = OTSManager.get_current().get_control().get_coordinator()
.register_resource(corbaReference);

Or can I somehow tell JTS/OTS transaction manager that my underlying JDBC XAResource implementation is the actual object I want to use.

The problem is that ResourcePOA methods' signatures dont have Xid argument, but rather transaction manager implicitly inserts Xid of the transaction in question.

OTS is designed to be interoperable with XA. The thing to remember first is that XA pre-dates OTS and whereas the latter is an object-oriented approach to transactions, the former never was. JTA is an attempt to impose an object-oriented methodology on XA, but most underlying implementations of XAResources are still procedural. JBossTS supports distributed transactions with XA (that's part of what the JTS/JTA implementation does) and there's more to it than mapping Xids: recovery is another element you need to consider.

However, if you'd just looking at a demonstration of what's involved, then you do need to wrap your XAResource in an OTS Resource. The Resource can get the Xid at registration time from the transaction context. It then just needs to remember this for when prepare/commit/rollback are eventually called.

[rookie1977]

Just to confirm that I have understood this correctly.

Since I have to wrap my JDBC XaResource with OTS Resource, then I also must keep by myself the mappings from the global Xid generated from external Transaction Manager to the Xid I will use with my JDBC driver, since I want to access the resource via JTA ( javax.transaction.xa.XAResource ).

And is this the right way to get the Xid from the transaction associated with the current thread:
String xid = org.omg.CosTransactions.TransIdentityHelper.id();

[rookie1977]

Just to add...

Since in my implementation of the org.omg.CosTransactions.ResourcePOA I will be just delegating to the true underlying XAREsource. For example, when Transaction Manager calls myImplementation.commit(), I will in the implementation of the myImplementation.commit() method perform delegation to the true XAResource.commit(XId), and thats why I have to keep mappings by myself.

[marklittle]

"rookie1977" wrote:
Just to confirm that I have understood this correctly.

Since I have to wrap my JDBC XaResource with OTS Resource, then I also must keep by myself the mappings from the global Xid generated from external Transaction Manager to the Xid I will use with my JDBC driver, since I want to access the resource via JTA ( javax.transaction.xa.XAResource ).

Yes. However, that's not such a hard task since you have that information when you register the resource.

And is this the right way to get the Xid from the transaction associated with the current thread:
String xid = org.omg.CosTransactions.TransIdentityHelper.id();

No. If you look in the CosTransactions.idl you'll see:

struct otid_t
 {
 long formatID; /* format identifier. 0 is OSI TP */
 long bqual_length;
#ifndef NO_ANONYMOUS_SEQUENCES
 sequence <octet> tid;
#else
 tranID tid;
#endif
 };

where the Xid is encoded within the tid.

[marklittle]

"rookie1977" wrote:
Just to add...

Since in my implementation of the org.omg.CosTransactions.ResourcePOA I will be just delegating to the true underlying XAREsource. For example, when Transaction Manager calls myImplementation.commit(), I will in the implementation of the myImplementation.commit() method perform delegation to the true XAResource.commit(XId), and thats why I have to keep mappings by myself.

Understood. But remember that one OTS Resource can only ever be associated with one transaction.

[rookie1977]

Am I wrong when I say that I will also need to made my global TrId=local TrId mappings part of recovery manager (I will need to disk-force at at certain times or whatever, and I will have to write something like my implementation of AbstractRecord) since these mappings are my own extension, and when RecoveryCoordinator during recovery phase comminucates with Resource object which wrapps my XAResource, I will have to read these mappings somewhere from non-volatile storage which survived the crash and delegate appropriate Xid to the true XaResource?

However, that's not such a hard task since you have that information when you register the resource.

Actually it is not hard but is an overhead, and I want to be sure that I do not have to implement critical parts of the system since I feel much comfortable to use code written and tested by experts, since I am not one (yet). I only want to know the true potential and features of JBossTS so that I dont have to reinvent the wheel, but when my implementation is neccessary, then that is what has to be done.

[marklittle]

I'll answer your latest posting later, but I do have a quick question: why don't you just use the JTS implementation of JTA? This does everything you are trying to do.

[rookie1977]

The previous posts are what seems to me the only way to do the following:
I want to expose my server side system (backed by XA capable JDBC driver) to be capable to participate in distributed transaction.

Is this (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=99487) the answer for the WS distributed transactions I am looking for?

And what is the best way (least coding effort) to expose my server side system to be capable to participate in distributed transactions via IDL?

I thought that my previous posts are the only way, and I am really not looking for the complete solution but rather only advice, just to know whether or not I am going in the right direction with following questions:
"What is the easiest/best way to expose server side system backed by XA JDBC driver to participate in distributed transaction via IDL (and Web Services)", and do I have to manually keep the mappings from global TrId to local TrId?

[marklittle]

If you go through the JTA interface, then all of this is taken care of for you by the JTS (note, nothing to do with Web Services: you will have to manage that yourself until we complete the automatic support). All you need do is create your XAResource at the right time and enlist it with the JTA transaction. JBossTS will maintain any mapping information.

Recovery may depend upon your XAResource implementation, but that's a subsequent step.

[rookie1977]

How can I get a reference to the com.arjuna.ats.internal.jta.transaction.arjunacore.subordinate.TransactionImple?

I specified that to be the value of the property "com.arjuna.ats.jta.jtaUTImplementation" in jbossjts-properties.xml and then I tried to get a reference to it by using Transaction Manager, but TM always returns com.arjuna.ats.internal.jta.transaction.jts.TransactionImple.

So how can I register above TransactionImple with the transaction manager, do I have to instantiate it myself and then register how?

[rookie1977]

I have finally figured it out. Thank you guys for your kind patience.