Fixes erroneous closing behavior in JtaConnection.java

[ljnelson]

Consider the use case where a method is annotated with jakarta.transaction.Transactional and close() is called on a Connection obtained therein. close() in this case should not actually close the Connection at that very moment, but closing should happen after the completion of the transaction. The prior version of this class was OK on the first point, and butchered the second point, so these changes fix the behavior. Note that the JtaConnection class is not currently used in Helidon, but will be soon.

[ljnelson]

@tjquinno I've incorporated your suggestion to bake an explicit state model into ConditionallyCloseableConnection without changing existing signatures etc. and without disturbing existing test behavior. While the change was a bit hairy for me to implement I greatly prefer it, so thank you for the suggestion. I'll resolve the other discussions above.

[danielkec]

@ljnelson Please add link to corresponding issue

[danielkec]

Can't we encapsulate this in AtomicReference for the sake of readability?

Enlistment enlistment = new Enlistment(t, xar);
if (!ENLISTMENT.compareAndSet(this, null, enlistment)) { // atomic volatile write
    // Setting this.enlistment could conceivably fail if another thread already enlisted this JtaConnection.
    // That would be bad.

[ljnelson]

Can't we encapsulate this in AtomicReference for the sake of readability?

Enlistment enlistment = new Enlistment(t, xar);
if (!ENLISTMENT.compareAndSet(this, null, enlistment)) { // atomic volatile write
    // Setting this.enlistment could conceivably fail if another thread already enlisted this JtaConnection.
    // That would be bad.

I'd rather keep the speedy and efficient VarHandle usage. (Additionally there is one static VarHandle for n occurrences of JtaConnection, not n occurrences of AtomicReference.)

[tjquinno]

I know it was work to use explicit states, but I think it's much clearer that way.

LGTM