Uploaded image for project: 'Red Hat Fuse'
  1. Red Hat Fuse
  2. ENTESB-16720

JPA persistence contexts not synchronized with JTA transactions propagation

XMLWordPrintable

    • False
    • False
    • % %
    • +
    • Automated
    • Undefined
    • Hide

      1 - There is a bean method named "TestService.performTest()", annotated with "javax.transaction.Transactional(TxType.REQUIRED)", which checks that no JPA entity instances are present in a DB, then it creates a NEW instance of the JPA entity in the current JTA transaction and then it invokes another bean method "NewTxTestService.testNewTransaction(...)".

      2- This new bean method "NewTxTestService.testNewTransaction(...)", annotated with "javax.transaction.Transactional(TxType.REQUIRES_NEW)", checks that the current JTA transaction is different from the previous one (which is received as parameter), then it retrieves all the instances of the JPA entity and then it verifies that no entity is returned (as they should be isolated in the previous transactional context).
       
      In conclusion, when there is a transaction chain where at some point a new transaction is spawned (for example by using the "javax.transaction.Transactional(TxType.REQUIRES_NEW)" annotation), the JPA operations, performed in the context of the new JTA transaction, are still executed using the firstly created JPA persistence context associated to the old suspended JTA transaction.

      Show
      1 - There is a bean method named "TestService.performTest()", annotated with "javax.transaction.Transactional(TxType. REQUIRED )", which checks that no JPA entity instances are present in a DB, then it creates a NEW instance of the JPA entity in the current JTA transaction and then it invokes another bean method "NewTxTestService.testNewTransaction(...)". 2- This new bean method "NewTxTestService.testNewTransaction(...)", annotated with "javax.transaction.Transactional(TxType. REQUIRES_NEW )", checks that the current JTA transaction is different from the previous one (which is received as parameter), then it retrieves all the instances of the JPA entity and then it verifies that no entity is returned (as they should be isolated in the previous transactional context).   In conclusion, when there is a transaction chain where at some point a new transaction is spawned (for example by using the "javax.transaction.Transactional(TxType. REQUIRES_NEW) " annotation), the JPA operations, performed in the context of the  new  JTA transaction,  are still executed using the firstly created JPA  persistence context associated to the old suspended JTA transaction.

      While Aries-JPA, and Aries-Transaction-Blueprint, indeed uses proxies to implement kind of "container managed persistence and transactions", there's one problem: Aries uses an "OSGi Coordinator service" that implements a nested unit-of-work behavior.
       
      Unfortunately[1], the actual Entity Manager is being looked up in current "coordination object" and, which is the reason of the problem, it continues "up" in case no Entity Manager is found.
       
      [1]https://issues.apache.org/jira/browse/ARIES-1346

              ggrzybek Grzegorz Grzybek
              emunoz@redhat.com Elkin Dario Munoz Duarte
              Stefan Veres Stefan Veres (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: