TransactionCoordinator using one phase commit for PESSIMISTIC locking

[dengansh]

Hi,

I noticed that the TransactionCoordinator performs a one phase commit in case PESSIMISTIC locking is used.

I understand that this is meant as an optimisation that can save 1 RPC, because all the locks have already been acquired on each write. This seems totally valid to me if just Infinispan is taking part in the transaction.

In a distributed transaction with multiple XA resources (e.g. Infinispan + database), however, I wonder if this optimisation is going a bit too far? Shouldn't the prepare phase do as much as possible to make it unlikely that the commit phase can fail? We would see HeuristicMixedExceptions and experience data inconsistencies in case the database transaction already has committed successfully...

Am I missing something? Or should this be changed in future Infinispan versions?

Cheers

Arne

[mircea.markus]

Very good question Arne.

Addind a prepare (1 network call) in order to check if the cluster is redundant as the tx originator would be informed by that by jgroups/the transport layer.

Now of course there is a chance for a node (or many nodes for that reason) to go down *after* prepare, before commit: we have transaction recovery in place that would help you to reconcile transaction's state in that case: https://docs.jboss.org/author/display/ISPN/Transaction+recovery

[dengansh]

Thanks for answering, Markus.

Clearly even 2PC does not prevent transaction recovery situations completely. 2PC has been designed, however, to make this as unlikely as possible. The TransactionCoordinator should never ignore 2PC, I believe, because it does add *some* extra safety, doesn't it?

Especially when integrating a 1PC resource (e.g. non-XA database) in a 2PC transaction, using the Last Resource Commit Optimization (LRCO, see https://access.redhat.com/knowledge/docs/en-US/JBoss_Enterprise_Application_Platform/5/html/Administration_And_Configuration_Guide/lrco-overview.html), the prepare phase should not be ommitted: LRCO performs the commit on the 1PC resource in the prepare phase. If the Infinispan prepare phase is left out, other Infinispan nodes wouldn't even know that we have a transaction recovery situation, would they?

Therefore I would suggest to change Infinispan to never do the 1PC optimisation in the TransactionCoordinator if it originally was a 2PC transaction. As the TransactionXaAdapter.commit method calls txCoordinator.prepare and txCoordinator.commit even in a 1PC situation, it could be changed to propagate the information "isOnePhase" to the TransactionCoordinator.prepare and commit methods. There, the 1PC optimisation must not be done if it originally was a 2PC transaction. (At least, this should be configurable.)

I can file a JIRA or even provide a patch if this helps. Please let me know.

Keep up the good work!

[mircea.markus]

Especially when integrating a 1PC resource (e.g. non-XA database) in a 2PC transaction, using the Last Resource Commit Optimization (LRCO, see https://access.redhat.com/knowledge/docs/en-US/JBoss_Enterprise_Application_Platform/5/html/Administration_And_Configuration_Guide/lrco-overview.html), the prepare phase should not be ommitted: LRCO performs the commit on the 1PC resource in the prepare phase. If the Infinispan prepare phase is left out, other Infinispan nodes wouldn't even know that we have a transaction recovery situation, would they?

Of course if last resosurce optimisation is in place(or if the prepare is marked onePhase==true for that reson) we don't ommit the prepare :-)

For 2PC though I'm not sure the prepare has any added value, as we'd only use for failure detection and there are other built in mechanisms that would inform us about a node leaving.