[jboss-jira] [JBoss JIRA] (WFLY-7108) UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown

UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: WFLY-7108 URL: https://issues.jboss.org/browse/WFLY-7108 Project: WildFly Issue Type: Feature Request Components: JPA / Hibernate Affects Versions: 10.1.0.Final Environment: *AppServer:* WildFly 10.1.0.Final *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar Reporter: Scott Marlow Assignee: Scott Marlow As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. *The obtained defect:* A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) *FIX:* We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... _Changes_: The method getSynchronizationType returns declared synchronization type. *Consequences:* We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction. Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call. It requires a declaration of synchronize persistence context. We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans. However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check. *Our actions:* We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization). This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false. _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d... *Example for reproduction:* I modified quickstart example: [^kitchensink-ear.rar] MemberRepository begin Extended UNSYNCHRONIZED Persistence Context. MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED. MemberRepository also perform join Transaction. Questions from [~smarlow]: - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it. We decided to use Container-managed EntityManager, because - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components - The container makes our job We want to use the existing mechanism *In Addition:* Formally, this is out of JPA SPEC, but we have the following reasons: - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?". But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given. ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach"