I suppose if it was decided by the
community it wasn't OK then perhaps there could be some API
that extended javax.transaction.xa.XAResource and provided by
"Jakarta Transactions 3" (let's say) which resources
compatible with the feature would be expected to implement and
when read-only is set to true if the XAResource provided to
the transaction manager was not one of these then some error
could be raised and the transaction rolled back.
That sounds like a good idea. Alternatively, how about
introducing a `default boolean supportsReadOnly() { return false;
}` and go with that? Same for TX isolation I guess.
I still think the isolation seems more the remit of the datasource management. But if it turns out not to be then this might be a way to go.
I expect the method you proposed would still go into a new class controlled by Jakarta Transactions given javax.transaction.xa.XAResource is part of Java SE, do you agree?
Am 08.12.2022 um 18:38 schrieb Tom Jenkinson:
> Thank you for the answers!
>
> The transaction manager won't be able to detect the
problem in the
> resource managers so it could still be that some
resources are written
> to during a transaction that is marked read-only, what
do people think
> to the usability aspects of that?
>
>
>
> On Thu, 8 Dec 2022 at 17:24, Christian Beikov
> <christian.beikov@xxxxxxxxx>
wrote:
>
> That code will be in Hibernate. Yes, we know when
an EntityManager
> is associated with a transaction and hence can do
these optimizations