The default TM included in jboss does not log
transactions. It therefore does not do recovery.
XA_RETRY is not in the spec, but it is in the javadoc.
I noticed some TMs have a policy for forgetting
heuristic commits which is what the jboss TM does without any policy configuration.
There is a logging TM being developed for jboss4,
the support for XA_RETRY has not changed.
The XA_RETRY is not in the JTA spec, but it is in the X/Open XA Spec. (page 33).
and it says:
"... The transaction manager should reissue xa_commit() at a later time."
The X/Open spec is part of the JTA spec by reference.
So does it mean that JBoss is not JTA compliant?
Yes, the TM included with jboss doesn't log
transactions so it cannot recover() or retry the
The javadocs for XA_RETRY say the operation
This is an excellent question. I believe the answers are:
1. Yes and No. No in that the RM is responsible for guranteeing that commit would or would not succeed by given the proper response from the prepare method. If a commit cannot succeed, then an XA_RETRY exeption should be thrown. Note that JBoss does not support retries though, so it's a delima. However, the wording on the spec on this matter is not very stong either:
"The resource manager is not able to commit the transaction branch at this time. [...] All resources held on behalf of *xid remain in a prepared state until commitment is possible. The transaction manager should reissue xa_commit() at a later time."
The word "should" means something very different than "must", so JBoss may be compliant by doing nothing, but just not very useful.
However, the answer is also yes because the X/Open spec states that the RM is required have access to persistent storage for the Xid's it is tracking during 2PC. This is how recovery is supported. The important thing is that any persisting has happend in prepare, before commit or rollback are called.
2. You could possible use the LoggingTxLogger or NIOMMLogPair classes, but I'm not sure they would be right for your needs.
3. The recover method is called during application server crash recovery. In order for this to be invoked, you would have to kill the app server when a global tx is in progress. The out-of-the box configuration of JBoss 4.0 doesn't use the recoverable transaction manager component, so that would need to be configured. I'm not exactly sure how that is done, maybe someone else knows?
I haven't really looked at the new TM in jboss4.
Since it is an MBean it should be possible to
list retryable transactions and allow them
to be completed. You could even schedule it.
I would expect your resource manager to also
provide this feature. There could be occasions
where the TM's peristent store is lost
or the TM was not able to contact the resource
manager for an extended period, you
need some mechanism to fix the in doubt transaction
The RM does persist that information on the host side (the communications RM does that by talking with the local (host) TM ) and it does provide mechanism to resolve in-doubt transactions locally.
The question is whether the RM part that runs inside the app. server (RA) should keep a persistent log as well.
(meaning that for each transaction, 3 persistent logs will be used:
1- the app. server's TM log
2- the RA log
3- the CRM log
very fast it wont be....