Fix #29365
Comment From: bclozel
See #29365 for context.
Comment From: reda-alaoui
:wave:
Comment From: jhoeller
Note that SharedEntityManagerCreator needs to be able to participate in JpaTransactionManager transactions as well as JtaTransactionManager transactions. In the latter case, it needs to lazily create an EntityManager and synchronize it with the ongoing transaction, assuming that the transaction manager setup and the persistence provider setup are able to participate in such an arrangement. This is the code path that executes for a multi-JpaTransactionManager scenario as well, it just tries to best-effort participate in the existing transaction. We cannot reliably determine whether such participation is intended and leading to correct results, so we leave that up to the application.
In terms of the effect of that isActualTransactionActive check, SharedEntityManagerCreator just asserts against obvious misuse of common write-related methods at an early point there. This is not meant to be a strict arrangement with consistent TransactionRequiredException throwing on our side. If we move on there and propagate the call to the target EntityManager, we effectively leave it up to the persistence provider - which might still reject that call. And if no write operation is attempted at all, we will effectively just reuse it as another transaction-scoped EntityManager instance for reading, side by side with the primary EntityManager that the original transaction operates on.