Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-7075

proposal (Extension): allow checking of mixed persistence context synchronization types to be skipped or to check if unsync context is already joined to JTA TX

    XMLWordPrintable

    Details

    • Type: Feature Request
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 10.1.0.Final
    • Fix Version/s: 11.0.0.Alpha1
    • Component/s: JPA / Hibernate
    • Labels:
      None
    • Environment:

      AppServer: WildFly 10.1.0.Final
      WildFly-jpa: wildfly-jpa-10.1.0.Final.jar

      Description

      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.
      WFLY-7108 is now the tracking jira for the fix.

      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 Scott Marlow:

      • 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:

        Gliffy Diagrams

          Attachments

          1. kitchensink-ear.rar
            396 kB
          2. Screenshot_10.png
            Screenshot_10.png
            4 kB
          3. Screenshot_7.png
            Screenshot_7.png
            9 kB
          4. Screenshot_8.png
            Screenshot_8.png
            5 kB
          5. Screenshot_9.png
            Screenshot_9.png
            5 kB

            Issue Links

              Activity

                People

                • Assignee:
                  smarlow Scott Marlow
                  Reporter:
                  veselroger Viacheslav Astapkovich
                  Involved:
                  kostd kostd
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  4 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: