Reordering of resources in commit of XA transaction

[patrickbradley]

If I have a bunch of XA resources and one non-XA resource, can I use them in an XA transaction? Will JBoss reorder the resources so that the non-XA resource is committed at the end of the first phase?

Here's an example:
Resource1: XA
Resource2: non-XA
Resource3: XA

Commit does the following:
- Prepare Resource1
- Prepare Resource3
- Commit Resource2 (1-phase)
- Commit Resource1
- Commit Resource3

[patrickbradley]

I agree that it is worthwhile. The absense of logging or recovery really hurts JBoss transactions, but implementing Last Resource is still a good step towards a more complete JTA solution.

This raises another question. With the partnership between Arjuna and JBoss, what kind of commitment does JBoss have to beefing up its own JTA (and JMS) solutions? Is it likely that we will see logging and recovery at some point, or will Arjuna + JBoss forever be the solution for those that are serious about JTA?

[marklittle]

Mark is correct, the default tm that comes with jboss 3.x does not support LRCO

It has been implemented for jboss4, I need to do some more testing on it
before backporting to 3.2.x
But since we don't do any logging/recovery either,
it is open to debate whether the optimization is of any serious worth.

Regards,
Adrian

[marc.fleury]

btw LRCO strikes me as a small benefit, almost a hack.

So in the case ONE resource doesn't support XA the XA protocol still works if that resource is last. (woo hoo!)

but heck if we can implement it for cheap why not

[marklittle]

I assume what you're after is the Last Resource Commit Optimization, but there may be a couple of things mixed in here.

Firstly, you don't have a choice as to what kind of resources are registered with JBoss TM - they have to be implementations of the XAResource interface since you're coming in through JTA. So, and here's where some of the confusion resides, if you want to register a non-XAResource participant but it's still two-phase aware, then you'd have to wrap it in an XAResource and ensure it obeys that protocol.

However, if what you've got is a resource (derived from, or wrapped by XAResource again, of course) that isn't two-phase aware, then you do need to LRCO. And fairly obviously you don't necessarily commit on the last resource.

Unfortunately it's not a required part of X/Open XA or JTA (JTA doesn't even mention it). Neither is ordering of participants in the transaction's intentions list, which you'd like to do for a number of other reasons.

I don't think JBoss TM supports it. If that is the case, the Arjuna+JBoss integration may be worth a look.

[adrian.brock]

Mark is correct, the default tm that comes with jboss 3.x does not support LRCO

It has been implemented for jboss4, I need to do some more testing on it
before backporting to 3.2.x
But since we don't do any logging/recovery either,
it is open to debate whether the optimization is of any serious worth.

Regards,
Adrian

[schrouf]

I do think that it is of serious worth, because it's better that nothing :-) Or am I wrong ?

Annotation

Further information on XA and a strategie for including a Non-XA-Resource in a XA transaction ( look for "Doing XA w/out an XA driver: the Last-Resource Gambit) can also be found in a good three-part article at

http://www.jroller.com/page/pyrasun/20040113
http://www.jroller.com/page/pyrasun/20040105#xa_exposed

and

http://jroller.org/page/pyrasun?catname=Java

[patrickbradley]

I agree that it is worthwhile. The absense of logging or recovery really hurts JBoss transactions, but implementing Last Resource is still a good step towards a more complete JTA solution.

This raises another question. With the partnership between Arjuna and JBoss, what kind of commitment does JBoss have to beefing up its own JTA (and JMS) solutions? Is it likely that we will see logging and recovery at some point, or will Arjuna + JBoss forever be the solution for those that are serious about JTA?

[marc.fleury]

btw LRCO strikes me as a small benefit, almost a hack.

So in the case ONE resource doesn't support XA the XA protocol still works if that resource is last. (woo hoo!)

but heck if we can implement it for cheap why not

[schrouf]

Exactly ! It's not perfect, but does the work in most cases. For example combined JMS and database transaction management with some 'more or less' popular Non-XA RDBMS ( e.g. 'MySQL' :-) would greatly benefit from this little extension !