[jboss-jira] [JBoss JIRA] (WFLY-7075) proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)

[Scott Marlow (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-7075:
-------------------------------
    Security:     (was: Red Hat Internal)


> proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-7075
>                 URL: https://issues.jboss.org/browse/WFLY-7075
>             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: Viacheslav Astapkovich
>            Assignee: Scott Marlow
>         Attachments: kitchensink-ear.rar
>
>
> 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/3bff5fde3cfc23f3999dc75c320029e69c562c40
> _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/195a8a65a9fae006ad603e425f6a16d896183ed2
> *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/message/5 )
> - 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"



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)