We are using Arjuna/Narayana XA transaction support for a project so we can have a single distributed transaction that spans multiple databases at the same time.
One of our databases is MySQL. Like many other databases, MySQL throws a certain type of error when an optimistic locking error is detected, which the application is supposed to interpret as "your transaction failed due to optimistic locking, but it will probably succeed if you just try it again so why don't you do that?"
Prior to using XA, this was not a problem, as it was easy to retry the transaction when an optimistic locking failure occurred - just check the type of exception, and retry if appropriate.
Now, however, Arjuna is treating the optimistic locking error as a fatal error just like any other, and there's no way for our code outside the overall XA transaction to know that the XA transaction is likely to succeed if retried (the exception is the same either way).
We don't want to retry every failed transaction, only the ones that failed due to optimistic locking. But we can't tell the difference.
Has anyone encountered this problem scenario with XA transactions, and if so how did you solve it?
