Hi community, I'm currently working on a TCK failure.
com.sun.ts.tests.jpa.core.enums.Client#setgetFlushModeEntityManagerTest_from_stateless3 This particular method https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/jpa/core/enums/Client.java#L955 In essence, it gets an entity manager from the container. It's a Stateless session bean, with Bean managed transactions. There is no transaction started. Then, it calls setFlushMode and right after getFlushMode to see if the change got applied. The issue with our implementation (or not) is that we do https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/persistence/JtaEntityManager.java#L258 So we get the current entity manager and then we delegate the call. The issue is that we call our JtaEntityManagerRegistry to get the current EntityManager if any or create a new one. https://github.com/apache/tomee/blob/master/container/openejb-core/src/main/java/org/apache/openejb/persistence/JtaEntityManagerRegistry.java#L85 As we are not in a transaction and we are not using an Extended Persistence Context, we create a new EntityManager every time, which means, the one used for set is not the one used for the get :-( The spec does not seem to cover this case https://jakarta.ee/specifications/persistence/3.0/jakarta-persistence-spec-3.0.html#container-responsibilities I quickly checked and both glassfish and wildfy have a new "invocation scoped" entity manager which is not part of the spec. One way would be to start a transaction at the beginning of the method so we have the guarantee to use the same underlying entity manager. -- Jean-Louis Monteiro http://twitter.com/jlouismonteiro http://www.tomitribe.com
