1 Reply Latest reply on Jul 29, 2016 1:00 PM by tomekadamski

    3 Transactions per action on stateless bean (LifecycleCMTTxInterceptor vs. CMTTxInterceptor)

    Tomas Cerny Novice

      Hello,

       

      I downloaded the Analyzer here GitHub - jbosstm/transaction-analyser: Monitoring tool for capturing detailed information of completed and in-flight tra… and tested the jboss-javaee6-webapp demo app.

       

      It seems according to both Analyzer and debugger that action call issues 3 transactions. In particular I call action register that calls controller and stateless bean (service). Naturally in CMT single transaction REQUIRED should exist, but I see three, 1 REQUIRED and 2 REQUIRES_NEW!

       

      In debugger I track

      1. CMTTxInterceptor#processInvocation picks REQUIRED and makes new transaction.

      2. LifecycleCMTTxInterceptor#processInvocation calls REQUIRES_NEW calls invokeInOurTx(invocation, tm, component);

      3. again LifecycleCMTTxInterceptor#processInvocation calls REQUIRES_NEW calls invokeInOurTx(invocation, tm, component);


      What is the difference with CMTTxInterceptor and LifecycleCMTTxInterceptor?

       

      It seems to me that CMTTxInterceptor is the actual business transaction and the LifecycleCMTTxInterceptor is responsible to initialise the stateless bean (some micro transaction not part of the business transaction).. ?

       

      The source code does not have much comments.

       

      When I do another use case that uses 3 session beans I get 7 transactions, which shows single REQUIRED transaction from CMTTxInterceptor and 6 times REQUIRES_NEW LifecycleCMTTxInterceptor


      Could you please provide me explanation on the outcome I receive?

        • 1. Re: 3 Transactions per action on stateless bean (LifecycleCMTTxInterceptor vs. CMTTxInterceptor)
          tomekadamski Novice

          Hi Tomas,

           

          LifecycleCMTTxInterceptor is executed before PostConstruct/PreDestroy method invocation. CMTTxInterceptor is executed around your business interface method. Please note that according to EJB 3.2 specification lifecycle methods of stateless session bean have "unspecified transaction context" and it is up to application server provider to decide in what transaction context such method will be executed. Wildfly wraps each stateless lifecycle bean invocation in the new transaction hence your analysis result.

          For more details please refer to point 8.6.7 of EJB 3.2 specification.


          Regards,

          Tomek