[infinispan-issues] [JBoss JIRA] (ISPN-11167) Retrying transactions after WriteSkewException should be easier

[Dan Berindei (Jira)]

Dan Berindei created ISPN-11167:
-----------------------------------

             Summary: Retrying transactions after WriteSkewException should be easier
                 Key: ISPN-11167
                 URL: https://issues.redhat.com/browse/ISPN-11167
             Project: Infinispan
          Issue Type: Bug
          Components: Core, Documentation
    Affects Versions: 10.1.0.Final
            Reporter: Dan Berindei
             Fix For: 11.0.0.Final


I've added the documentation tag because we "know" users of optimistic transactions
should catch {{WriteSkewException}}s and retry, but the user guide never explains how a user should do it.

It turns out the exception tree is really complicated:

{noformat}
javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1299)	Suppressed: javax.transaction.xa.XAException
		at org.infinispan.transaction.impl.TransactionCoordinator.prepare(TransactionCoordinator.java:143)
    Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from ...
		at org.infinispan.remoting.transport.ResponseCollectors.wrapRemoteException(ResponseCollectors.java:25)
		Suppressed: org.infinispan.util.logging.TraceException
			at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.get(SimpleAsyncInvocationStage.java:39)
	Caused by: org.infinispan.transaction.WriteSkewException: Write skew detected on key ...
		at org.infinispan.marshall.exts.ThrowableExternalizer.readObject(ThrowableExternalizer.java:257)
{noformat}

Part of the problem is internal: we shouldn't wrap {{WriteSkewException}} in a {{RemoteException}}.

The other part is harder to control: Narayana makes our {{XAException}} a suppressed exception instead of a cause,
probably because in the general case multiple XA resources could fail to prepare.

Initially I thought the XAException was suppressed because Narayana committed the transaction in one phase,
but I disabled {{CoordinatorEnvironmentBean.commitOnePhase}} and it's still suppressed.


OTOH the exception tree could be much simpler with {{useSynchronization(true)}},
if it weren't for our own gratuitous wrapping:

{noformat}
javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.
	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1299)
Caused by: org.infinispan.commons.CacheException: Could not prepare.
	at org.infinispan.transaction.impl.TransactionTable.beforeCompletion(TransactionTable.java:898)
Caused by: javax.transaction.xa.XAException
	at org.infinispan.transaction.impl.TransactionCoordinator.prepare(TransactionCoordinator.java:143)
Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from ...
	at org.infinispan.remoting.transport.ResponseCollectors.wrapRemoteException(ResponseCollectors.java:25)
	Suppressed: org.infinispan.util.logging.TraceException
		at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.get(SimpleAsyncInvocationStage.java:39)
Caused by: org.infinispan.transaction.WriteSkewException: Write skew detected on key ...
	at org.infinispan.marshall.exts.ThrowableExternalizer.readObject(ThrowableExternalizer.java:257)
{noformat}

We could remove the {{CacheException}}, the {{XAException}}, and the {{RemoteException}},
leaving just a {{RollbackException}} caused by a {{WriteSkewException}}.


For implicit transactions we add yet another wrapper:
sync operations wrap the {{RollbackException}} in a {{CacheException}},
async operations wrap it in a {{CompletionException}}.
We could instead check if the exception is caused by a {{WriteSkewException}} and unwrap it.

We should definitely add a helper static method for the users to check if they should retry the transaction,
something like {{CacheTransactions.isWriteSkew(RollbackException)}}, 
and we should change the write skew to use it.
Currently they are content to catch a {{RollbackException}} and assume it has a {{WriteSkewException}} inside.

We should also add a {{useSynchronization}} parameter to {{AbstractClusteredWriteSkewTest}} and all the write skew tests.



--
This message was sent by Atlassian Jira
(v7.13.8#713008)