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