Better exception when accessing two non-XA datasources in a transaction about quarkus

[mmusgrov]

I assume that Agroal is swallowing the exception so just report that as the root cause, ie changing the JTA enlistment semantics is not the correct approach. Note that there is an open PR to allow mulitple XA unaware resources (#40365) .

[yrodiere]

I assume that Agroal is swallowing the exception

@mmusgrov There is no exception from Narayana here, just a method returning a boolean:

https://github.com/agroal/agroal/blob/30465b6eaae28366449832e1ee22bbe8a9b83562/agroal-narayana/src/main/java/io/agroal/narayana/NarayanaTransactionIntegration.java#L120-L122

so just report that as the root cause

I can't, see above :)

Note that there is an open PR to allow mulitple XA unaware resources (#40365) .

Yes I'm aware of that, having been involved quite a bit xD As we discussed though, this is a temporary solution. We need to think of longer term solutions, and providing clear exception messages when someone tries to do something incorrect is the first step.

[mmusgrov]

So can we enable arjuna logging (unless there are already warnings) to see why the enlist call returns false?

[mmusgrov]

If "Agroal 2.3+ now makes it possible to detect that an application is accessing two non-XA datasources in a transaction" why does it still attempt the enlistment?

[mmusgrov]

I need more information in order to provide a better analysis of why the enlist is failing.

[mmusgrov]

@shawkins and @yrodiere Also note that in the multiple one phase aware resources case, if the first one phase aware resource commits and the second one rolls back then overall result reported back to the caller is rollback even though the first one committed (they ought to get a heuristic outcome) and I am fixing that at the moment (I'm on a national holiday today so it may have to wait until tomorrow to be completed). Since we never anticipated use of multiple one phase resources I am busy testing it now and writing test cases where I find deficiencies.

[yrodiere]

If "Agroal 2.3+ now makes it possible to detect that an application is accessing two non-XA datasources in a transaction" why does it still attempt the enlistment?

It "makes it possible to detect" by implementing that LastResource* interface. Agroal doesn't do the detection itself, Narayana does, during enlistment, and it just returns a boolean with no information that Agroal can pass over to the user.

@shawkins and @yrodiere Also note that in the multiple one phase aware resources case, if the first one phase aware resource commits and the second one rolls back then overall result reported back to the caller is rollback even though the first one committed (they ought to get a heuristic outcome) and I am fixing that at the moment (I'm on a national holiday today so it may have to wait until tomorrow to be completed). Since we never anticipated use of multiple one phase resources I am busy testing it now and writing test cases where I find deficiencies.

Good to know, thanks. And this all definitely can wait until tomorrow (or later) as far as I'm concerned, so don't feel forced to work today :)

[mmusgrov]

So is the test adding the two XA unaware resources with the allowUnsafeMultipleLastResources property implemented and set? If so then that is probably enough for me to reproduce the problem. But if the test is doing something else then I need more information to determine why the second resource is being rejected.

[shawkins]

So is the test adding the two XA unaware resources with the allowUnsafeMultipleLastResources property implemented and set? If so then that is probably enough for me to reproduce the problem.

@mmusgrov Yes with allowUnsafeMultipleLastResources not enabled, then the second Connection access like this shawkins/quarkus-quickstarts@014e306#diff-761c636458b29cbabf9e4f4b500472088e222e1310327cade67b7db30a8febb0R25 will result in the exception in the description.

The AddOutcome is AR_DUPLICATE, but the calling logic is treating that the same as AR_REJECTED - https://github.com/jbosstm/narayana/blob/ae4755680f1e5dc7988f8525d1352d24a8adfffd/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/TransactionImple.java#L638

[yrodiere]

So is the test adding the two XA unaware resources with the allowUnsafeMultipleLastResources property implemented and set?

You don't need allowUnsafeMultipleLastResources. This exception arises when you access two non-XA datasources in a single transaction, which by default is not allowed since Quarkus 3.8.2, as we're all quite aware by now :)

This is the exact problem we've been discussing for the past week(s), but I'm talking about a different improvement in that area:

• Previous GitHub issues/PRs were all about finding workarounds for people who need to use two datasources in the same transaction (temporarily, because it's a bad idea).
• This GitHub issue is about making sure that when it's not allowed (the default), the exception message people get is actionable, i.e. explains what's wrong exactly (at least) and what can be done to avoid it (ideally).

If so then that is probably enough for me to reproduce the problem. But if the test is doing something else then I need more information to determine why the second resource is being rejected.

Just access two Agroal, non-XA datasources in the same transaction, in Quarkus 3.8.2 or 3.9.latest or 3.10.latest or Quarkus main, and you'll get this exception.

[mmusgrov]

Thanks @shawkins , I'll look into creating a narayana unit test to duplicate this behaviour.