JtaConnection prohibits enlistment into a transaction whose status is STATUS_MARKED_ROLLBACK

[ljnelson]

(Not sure whether this is correct behavior or not.)

helidon/integrations/jta/jdbc/src/main/java/io/helidon/integrations/jta/jdbc/JtaConnection.java

Line 1004 in 61adad5

case Status.STATUS_MARKED_ROLLBACK:

While the transaction in question is irrevocably doomed, "marked for rollback" seems to be considered an active-like status. See also https://www.eclipse.org/lists/jta-dev/msg00258.html and following.

Whether this is correct behavior or not, the method's javadoc also does not align with its current behavior so one thing or the other needs to be addressed.

[ljnelson]

The rabbit hole goes deep. You certainly do not want to permit a connection that has just been acquired to enlist (its associated XAResource) in a transaction that is marked for rollback. Or, even if you decide to permit it, the registration machinery itself will reject the request.

One thing that is true is: while checking for a pre-existing enlistment, that enlistment's associated Transaction may very well be in the Status.STATUS_MARKED_ROLLBACK state, and that is entirely legal. Need to check that this is in fact allowed in JtaConnection.

So probably in JtaConnection the overall behavior should not be changed, but the class' innards should be moved around and refactored somewhat to allow the JTA implementation itself to reject enlistment attempts, even when we know they're doomed in advance. Simpler code, and user problems with such state transitions would then no longer be Helidon's responsibility.

[ljnelson]

User desires to do fancy and/or possibly not quite right things with rollback-only transactions might be able to be accomplished by twiddling various JPA provider parameters, such that the provider, for example, acquires a single connection for the life of the EntityManager: in such a case, no subsequent enlistment attempts will be made once the transaction goes to rollback-only and there is at least the possibility that a rogue read (a "harmless" transactional operation) will succeed. Eclipselink has such a parameter; not sure about Hibernate.

[ljnelson]

See also: https://www.eclipse.org/lists/jta-dev/msg00321.html

[ljnelson]

After a great deal of work and investigation: it is apparently correct and proper for a JTA implementation (such as Narayana) to reject enlistment of a resource in a transaction that is marked for rollback only (see, for example: https://github.com/jbosstm/narayana/blob/7.0.0.Final/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/TransactionImple.java#L417-L419).

The recently merged PR associated with this issue (#8479) does not (and cannot) change this. However, the PR does allow for the JTA implementation itself to enforce restrictions and prohibitions. With the behavior implemented by the PR activated (see the PR's description), you will see that Narayana itself will prevent the enlistment. The net behavior will be the same, but you should be able to see that it is not Helidon that enforces the restriction.

A wrinkle: Once a resource has been enlisted, i.e. when the transaction was active and before it was marked for rollback, that resource should continue to function just fine, so long as you don't do anything with it that results in commit-like behavior. So, for example, where JPA is concerned as noted above you can usually tell it to use exactly one connection and none other on the thread associated with the current transaction, and so, if you do that, and the connection gets enlisted while the transaction is active, then when the transaction is marked for rollback the resource (the connection) is already enlisted so you can keep using it if that's really what you want to do. (Hint: it's rarely what you want to do.)

Given all this, I'm going to close this issue, not because you can now do what you want to do (you can't, really, and never could), but because it was not and is not a bug in Helidon itself. Perhaps it is a bug (unlikely) in Narayana or the JTA specification itself, or perhaps the restriction exists for good reason. I'm not entirely sure.

On that subject: I have an outstanding question to the JTA expert group around why enlistments are prohibited, given that with some clumsy effort you can actually work around this with some TransactionSynchronizationRegistry gymnastics. See https://www.eclipse.org/lists/jta-dev/msg00323.html. It usually takes the group about a month or two to respond to emails received on the list.