Uploaded image for project: 'IronJacamar'
  1. IronJacamar
  2. JBJCA-1492

CachedConnectionManager: incorrect handling of REQUIRES_NEW

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • None
    • None
    • None
    • None

      CachedConnectionManager lazy transaction enlistment doesn't work correctly with nested transaction. The problem was discovered when transactions were managed by spring framework, but in general correct usage of UserTransaction APImay lead to incorrect behavior that can compromise data integrity. The scenario can be shown on a following example:

      
      void outer {
          //1
          foo();
          //7
          showLog();
      }
      
      
      @Transactional(REQUIRED)
      Foo foo {
          //2 
          log("BEGIN");
          //3
          TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
          //4
          Foo foo = em.find(Foo.class, id);
          //5
          log("END");
          //6
          showLog();
          return foo;
      }
      
      @Transactional(REQUIRES_NEW)
      void log(String a) {
          //adds a logged string into database
          (...)
      }
      
      void showLog(){
          //prints log entries from the database
          (...)
      }
      
      

      In 1 invocation of a foo method leads to creation of a transaction A but no connection is yet created so nothing is added to CachedConnectionManager records. In 2 new transaction B is created and transactionStarted notification is performed but since there is nothing in CCM records it has no result. The transaction finishes successfully. In 3 we are marking transaction A as rollback only. In 4 database search results in connection creation. The connection is added to CCM. In 5 new transaction C is created but this time record created in point 3 is present in CCM records so it is enlisted in transaction C (BUG). In 6 log shows both BEGIN and END records. In 7 after transaction A rollback only record "BEGIN" is present in the database.

              tadamski@redhat.com Tomasz Adamski
              tadamski@redhat.com Tomasz Adamski
              Votes:
              6 Vote for this issue
              Watchers:
              10 Start watching this issue

                Created:
                Updated: