Yes, all in flight transactions will remain in-flight until the transaction
manager can heuristically determine that they should be rolled back or
committed, which happen when the transaction manager is informed about the
state of the various transactional resources (in our case, the JDBC
I fully agree.. The even bigger problem is that people do not really
understand what recoverable means at all.
Until recently my understanding was that without recovery all running
transactions would simply be rolled back in case of a crash .. but this
does not seem to be the case.
Luckily I
I think we should clearly document the level of safety using those pooling
mechanism.
Afaik, hikari and dbcp2 do not support automatic transaction recovery, the
only combinations I'm aware of are:
* aries transaction manager + pax-jdbc-pooling-aries
* narayana transaction manager +
I have documented how the new pooling and XA support works.
I think the new support is much more straightforward to use and gives
better error reporting.
For example in the old pooling support if you use the pooling and xa
enabled DSF "H2-pool-xa" and forget to install a TransactionManager
