JBossTS/JCA Recovery work for JBoss 4.2

[weston.price]

Currently in the 4.2 branch the

org.jboss.resource.connectionmanager.xa.JcaXAResourceWrapper

has been provided for two reasons:

1) We needed a way to override the isSameRM method to address a well known WebSphereMQ bug where mutliple XAResouces could not be enlisted in the same transaction from the same RM. Basically this simply amounted to moving the isSameRM stuff that was originally done for Oracle to be more generic.

2)Provide a serializable wrapper to support XA resource recovery using JBossTS.

It was my plan to use this wrapper both on the inbound and outbound for JCA. From my understanding, this would enable JBossTS to reconsruct the XAResource and call recover as the XAResource (in this case the wrapper) would be written to the transaction log enabling JBossTS to do it's thing.

I wanted to throw this out in the forum just be sure I am not missing anything and to solicit advice as to if this is the appropriate approach to take. The alternative approach would be to implement the

com.arjuna.ats.jta.recovery.XAResourceRecovery

interface and do things in the same manner as the JMS recovery work.

Thoughts?

[timfox]

I'm probably misunderstanding what you're doing here, but for JMS the recovery manager interfaces with the jms provider via an XAResourceRecovery instance - i.e. there's no JCA involved.

Are you suggesting that all XA recovery is driven via the JCA adapter?

[weston.price]

I'm probably misunderstanding what you're doing here, but for JMS the recovery manager interfaces with the jms provider via an XAResourceRecovery instance - i.e. there's no JCA involved.

For JCA inflow, it has to be through JCA as I am the one initiating the transaction calling XASession.getXAResource() so I am not sure how your recovery stuff would come into play. Also, for outbound connections (ie JDBC) this has to be done to properly register recoverables with JBossTS.

[bill.burke]

2)Provide a serializable wrapper to support XA resource recovery using JBossTS.

It was my plan to use this wrapper both on the inbound and outbound for JCA. From my understanding, this would enable JBossTS to reconsruct the XAResource and call recover as the XAResource (in this case the wrapper) would be written to the transaction log enabling JBossTS to do it's thing.

One issue with this is that the user that executed the original transaction may not have permission to perform a recovery. For instance, only a DBA may have the permission to perform recovery on the database. Also, because the XA spec is a bit ambiguous, different XAResources of different vendors may have different requirements on what flags you pass into XAResource.recover(). There's also the general problem that some XAResources require Xid padding and others don't. I'm guessing that JBoss TS solves the latter two problems in very very hacky ways that are easy to break as there is no defined integration contract between JBoss, JBoss JCA, and Arjuna. I do not know how or if they solve the permission problem.

[timfox]

For JCA inflow, it has to be through JCA as I am the one initiating the transaction calling XASession.getXAResource() so I am not sure how your recovery stuff would come into play. Also, for outbound connections (ie JDBC) this has to be done to properly register recoverables with JBossTS.

Why does it matter who initiated the tx?

For recovery with JBoss TS, as long as you have provided an XAResourceRecovery instance, the recovery manager will call upon that to get an XAresource then call recover() on that to get the list of xids from the resource manager. (You can also make the XAresource serializable but that is another story)

The recovery manager will then call commit or rollback on them as it deems appropriate.

I don't see what relevance it has who started the transaction.

[weston.price]

Sorry, I should have been more clear. You are outlining the case for JBM. The JMS/JCA adapter had to account for multiple foreign providers, not just JBM.

[timfox]

You are outlining the case for JBM. The JMS/JCA adapter had to account for multiple foreign providers, not just JBM.

Not really. JBoss TS recovery works that way for any XAResource - whether it's from JBM, a database, or whatever.

[timfox]

Also, not everyone that wants recovery will be using JCA.

I guess I'm still missing something, but I don't really see why recovery is being viewed as the responsibility of JCA. They seem orthogonal to me.

Have I totally misunderstood this thread? :)

[weston.price]

Not really. JBoss TS recovery works that way for any XAResource - whether it's from JBM, a database, or whatever.

Huh? The underlying XAResource either has to be serializable, or the the XAResourceRecovery interface has to be implemented to support recovery via JBossTS.

Can we agree on that ;-)

[weston.price]

I think we may be crossing wires ;-)

Also, not everyone that wants recovery will be using JCA.

This is true, but in JCA land, to support recovery one approach (ie serializable XAResource or XAResourceRecovery implementaion) has to be done. Just as you had to do this for JBM, JCA needs to support this as well to integrate with JBossTS.

[timfox]

Not really. JBoss TS recovery works that way for any XAResource - whether it's from JBM, a database, or whatever.

Huh? The underlying XAResource either has to be serializable, or the the XAResourceRecovery interface has to be implemented to support recovery via JBossTS.

Can we agree on that ;-)

I was just saying, that (for JBoss TS at least) you can write an XAResourceRecovery instance that will provide an XAResource on which the tx mgr can call recover(). This shouldn't be any different for any provider.

Whether the transaction was started by JCA or not (e.g. for inflow) should be of no consequence.

When the recovery manager calls recover() the resource manager is supposed to return a list of in doubt xids, whether they were started by JCA, some user application, or your great Aunt Doris.

I still don't see what any of this has got to do with JCA.

[timfox]

This is true, but in JCA land, to support recovery one approach (ie serializable XAResource or XAResourceRecovery implementaion) has to be done. Just as you had to do this for JBM, JCA needs to support this as well to integrate with JBossTS.

I disagree.

Let's take the example of JBM for a minute. We already have a recovery mechanism in place (we use an XAResourceRecovery instance).

Now whether the transaction was started via JCA or directly by the user is of no consequence.

The JBoss TS recovery manager will just get an xaresource from our XAResourceRecovery instance and return a list of xids, some of these may come from transactions initiated by JCA and others not. It doesn't matter.

In this scenario there is absolutely no need for JCA to do anything.

I think the same logic applies to any resource manager for which you can write an XAResourceRecovery.

[weston.price]

I disagree.

Let's take the example of JBM for a minute. We already have a recovery mechanism in place (we use an XAResourceRecovery instance).

That's fine. In this case, because you implemented XAResourceRecovery, you are able to integrate with JBossTS directly. This is the situation you control...all fine well and good.

Now, how about for XAResources you don't control? How about Oracle, DB2, WebSphereMQ, etc. What about those?

How do you think these XAResource get enlisted in a transaction to begin with and who provides access to them? Guess what, it's JCA. ResourceManagers (JMS, JDBC or otherwise) are managed in an EE environment via JCA. Because JCA is a generic framework for resource integration use of the underlying XAResource is governed by this framework. There is no concept of a standalone ResourceManager in an EE environment without an associated JCA resource adapter...well, other than in the case where the person is just blatantly attempting to do something wrong, Aunt Doris or otherwise.

For your fundamental disagreement to hold water, you would effectively have to remove JCA from the equation all together and assume that the Tx Manager has direct access the underlying XAResources/ResourceManagers *without* JCA intervention. This is simply not the case and will never be the case in our Application server, or any compliant EE application server for that matter.

[weston.price]

Put another way ;-)

Take the case of say an RDBMS system..let's take our friend Oracle for an example. Oracle is deployed, managed, utilized in JBossAS via our JCA JDBC Resource adapter. It is the adapter that manages resource enlistment/delistment of the underlying XAResource...in sum, JCA takes care of all the messy details of driving the underlying managed connection through the XA transaction lifecycle (and pooling, security etc).

So, who implements the XAResourceRecovery interface in this case? In other words, how does the underlying Oracle XAResource participate in recovery assuming that the vendor doesn't provide the necessary mechanism to do so?

[bill.burke]

Tim, if you do it your way, won't recovery not work for JBMessaging in other app servers?