Two Phase Commit question

[talg]

Hi,

I'm writing a RA that connects to a remote transaction system.

On the remote transaction system I wrote a CRM (Communications Resource Manager) that wills serve as an agent to the TM.

I ran some simulations on jboss, accessing two transactions in the same global transaction. both voted XA_OK on the prepare.
when the commit for the first branch was called, it returned XA_RETRY (4) since the CRM on the remote machine was temporarily unavailable.

The TM, ignored it, and it called Commit on the other branch, and then forget on the branch that asked for a retry.

is it the RM responsibility to log the decision to commit the transaction, and to do it in it's one will? if that's true, is there a logging service that i can utilize in jboss to persistently store the decisions?

Also, I'm not sure why it called the forget method. suppose I was going to harden the decision to commit the transaction on the entry to the commit method, but failed to access the log. the transaction on the remote system will get to in-doubt state. i will never know whether to commit it or to toll it back.

so bottom line questions:
1. is it the RM responsibilty to harden the commit and rollback decisions?

2. if so, is there a mechanism in jboss that i can reuse

3. when does jboss TM call the recover method. couldn't get that to happen....

Thanks,
Tal

[adrian.brock]

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.

Regards,
Adrian

[talg]

Thanks.

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."

[adrian.brock]

The X/Open spec is part of the JTA spec by reference.

Regards,
Adrian

[talg]

So does it mean that JBoss is not JTA compliant?

[adrian.brock]

Yes, the TM included with jboss doesn't log
transactions so it cannot recover() or retry the
commit() later.

The javadocs for XA_RETRY say the operation
maybe retried?

Regards,
Adrian

[kbirch]

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?

cheers,
kevin

[adrian.brock]

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
locally.

Regards,
Adrian

[talg]

Thanks,

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....

Tal