For example, the first container rule described in [2] states:
"
The container creates a new entity manager by
calling EntityManagerFactory.createEntityManager when the first
invocation of an entity manager with
PersistenceContextType.TRANSACTION occurs within the scope of a
business method executing in the JTA transaction.
"
While the above rule applies to EJBs, it also applies to other components as well. It is not a difficult rule to implement but still it is the responsibility of the EE/Persistence container to perform. If an EE implementation does not do this then the application would have to call joinTransaction() but shouldn't have to.
There might be a small confusion here.
In [1] it wasn't a question about whether the EntityManager was container managed or not. That is absolutely clear. It should be managed. The application doesn't need to call joinTransaction() or anything like that.
The question is just whether the responsibility of managing it should be with the application server code (Jakarta EE implementation / runtime, such as WildFly or GlassFish) or the Jakarta Persistence implementation code (Hibernate, OpenJPA, EclipseLink etc).
I think placing the implementation code in the application server is historial; the APIs to manage the entity manager as per the contract weren't available then. Today Hibernate etc would be able to do this too using modern EE APIs.
Kind regards,
Arjan Tijms
