So you are referring to a scenario where a user marks a TX as read-only,
but some XAResource that is part of that TX doesn't support this, right?
Yes, that is essentially the scenario.
I think it's "ok" that the TX doesn't fail in such a scenario when
writes happen to such a XAResource. It's a limitation of the XAResource,
and if read-only semantics can't be implemented for that resource, the
implementer could emit a warning.
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.
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
