[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ] Viacheslav Astapkovich commented on WFLY-6127: ---------------------------------------------- *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 ExtendedEntityManager class ALWAYS returns SYNCHRONIZED type of synchronization. *FIX:* We created 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... Corrections: The method getSynchronizationType returns declared synchronization type. *Effect:* We use our own realization of Martin Fowler’s pattern "Unit of Work". We initialize Unsynchronized Extended Persistence Context and our realization controls the synchronization with transaction. Our Beans can be controlled by UnitOfWork, as well as be used as a part of WebService. This requires the declaration of synchronized persistence context. We catch IllegalStateException after we have fixed the defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we declare synchronized persistence context in our beans. However, our UnitOfWork realization controls synchronization of persistence context and we can synchronize context before the synchronization type check. *Our actions:* We had to add the possibility to check synchronization type in the testForMixedSynchronizationTypes method of TransactionScopedEntityManager class by isJoinToTransaction method (i.e. the actual type of synchronization). This ability is realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property is set to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. The system operates as usual if this property is not defined or set to false. *Commentary:* Though our actions deviate from JPA SPEC, we have a valid reason for acting this way: - A question arose in the development process of the JPA specification : "Should we relax this if the PC has been joined to the transaction?". Unfortunately, no feedback was given and Linda DeMichiel decided to keep it as it was ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... ) - We also found a JIRA task https://java.net/jira/browse/JPA_SPEC-6 . And it was closed too because "No feedback in favor of changing current approach" -- This message was sent by Atlassian JIRA (v6.4.11#64026)