Uploaded image for project: 'Application Server 7'
  1. Application Server 7
  2. AS7-5329

Transaction leak protection for web requests is too restrictive (possibly violating the spec)

XMLWordPrintable

    • Workaround Exists
    • Hide

      It's possible to uninstall TransactionRollbackSetupAction from custom extension, by installing a DeploymentUnitProcessor containing a code like this:

         @Override
         public void deploy(DeploymentPhaseContext phaseContext) throws DeploymentUnitProcessingException {
      
               final List<SetupAction> setupActions = du.getAttachmentList(org.jboss.as.ee.component.Attachments.WEB_SETUP_ACTIONS);
      
               int i=0;
               for (SetupAction a: setupActions)
               {
                  if (a instanceof TransactionRollbackSetupAction)
                  {
                     setupActions.remove(i);
                     break;
                  }
                  i++;
               }
           }
      

      Deployment processor has to be installed for PARSE phase with order number higher than Phase.PARSE_TRANSACTION_ROLLBACK_ACTION.

      Show
      It's possible to uninstall TransactionRollbackSetupAction from custom extension, by installing a DeploymentUnitProcessor containing a code like this: @Override public void deploy(DeploymentPhaseContext phaseContext) throws DeploymentUnitProcessingException { final List<SetupAction> setupActions = du.getAttachmentList(org.jboss.as.ee.component.Attachments.WEB_SETUP_ACTIONS); int i=0; for (SetupAction a: setupActions) { if (a instanceof TransactionRollbackSetupAction) { setupActions.remove(i); break ; } i++; } } Deployment processor has to be installed for PARSE phase with order number higher than Phase.PARSE_TRANSACTION_ROLLBACK_ACTION.

      In order to prevent leaking active transactions from processing of web requests a TransactionRollbackSetupAction is installed by transactions subsystem for web subsystem to use. This causes usecases where we want JTA TX to span different web apps over cross-context includes to fail, as the setup action is applied around each cross-context include, and forcefully rolls back any TX still active at the end of dispatching.

      A concrete use case are portals that rely on cross-context includes.

      Java EE Platform 6 Spec says the following in section EE.4.2.2:

      "Returning from the service method to the network client with an active transaction context is an error. The web container is required to detect this error and abort the transaction.

      As specified above in Section EE.4.2.1.2, “Transaction Non-Requirements,” requests made within a web container using the RequestDispatcher must propagate any transaction context to the called class. Unless the called class commits or aborts the transaction, the transaction must remain active when the called class returns."

      There is no talk here about cross-context includes or application boundaries. Therefore it seems the current implementation is not spec-compliant.

      TransactionRollbackSetupAction should only be applied on an original incoming web request, not on each cross-context include.

              bstansbe@redhat.com Brian Stansberry
              marko.strukelj@gmail.com Marko Strukelj
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: