Mule
  1. Mule
  2. MULE-3382

Replace jms:xa-transaction node with a generic xa-transaction element

    Details

    • User impact:
      High
    • Effort points:
      0.5
    • Similar Issues:
      MULE-2018Provide a default TX action if an XA transaction detected and no endpoint TX action available
      MULE-10XA Transaction support
      MULE-7098Create automated test cases for xa transaction recovery
      MULE-3563XA JDBC Connection never enlist to XA transaction
      MULE-8693XA transaction must set tx timeout in XA resources
      MULE-4887timeout parameter in xa-transactions is completelly ignored
      MULE-1776XA transactions bug with simple queue to queue using Websphere MQ 6
      MULE-6051XA transactions causing an increment in ActiveMQ consumers
      MULE-4486IllegalTransactionStateException bridging ActiveMQ to ActiveMQ in a XA Transaction
      MULE-442XA transactions not working with Jms

      Description

      There must be no jms:xa-transaction config element, but a core xa-transaction one instead.

        Issue Links

          Activity

          Hide
          Dirk Olmes added a comment -

          There are currently two schools of thought on how to implement this:

          1. allow an xa-transaction element on generic endpoints even though not every transport supports that. It would be the user's responsibility to configure the xa-transactions correctly (or Mule would blow up at runtime when starting up)
          2. allow XA transactions only on transport specific endpoints which support XA. Note that configuring XA transactions on generic endpoints would then only be possible by using the current approach: using a custom-transaction element and specifying the XATransactionFactory.

          IMHO approach 2) would be much less error prone and IMHO aligns better with the approach we have used for configuring Mule through XML: make the configuration as tight as possible and catch runtime errors in the config already, where possible.

          Show
          Dirk Olmes added a comment - There are currently two schools of thought on how to implement this: allow an xa-transaction element on generic endpoints even though not every transport supports that. It would be the user's responsibility to configure the xa-transactions correctly (or Mule would blow up at runtime when starting up) allow XA transactions only on transport specific endpoints which support XA. Note that configuring XA transactions on generic endpoints would then only be possible by using the current approach: using a custom-transaction element and specifying the XATransactionFactory. IMHO approach 2) would be much less error prone and IMHO aligns better with the approach we have used for configuring Mule through XML: make the configuration as tight as possible and catch runtime errors in the config already, where possible.
          Hide
          Ross Mason added a comment -

          I agree that 2) is the better approach but you don't need to use the custom-transaction approach. Instead you just need to add a Bean Definition parser for JDBC, VM and JMS for XA transactions i.e. <jms:xa-transaction action=...>, <jdbc:xa-transaction action=...>

          Show
          Ross Mason added a comment - I agree that 2) is the better approach but you don't need to use the custom-transaction approach. Instead you just need to add a Bean Definition parser for JDBC, VM and JMS for XA transactions i.e. <jms:xa-transaction action=...>, <jdbc:xa-transaction action=...>
          Hide
          Daniel Feist added a comment -

          There is actually a third option:

          3. Allow XA transaction element only on transport specific endpoints that support XA and also allow it on generic endpoints. So you would be able to configure them on "endpoint" and jms:endpoint" but not on "smtp:endpoint" for example.

          Ross:
          The approach with 2) would be to have a single element in mule.xsd which is used from each transport schema, there is no need to have transport specific XA transaction elements. See MULE-3382.

          Show
          Daniel Feist added a comment - There is actually a third option: 3. Allow XA transaction element only on transport specific endpoints that support XA and also allow it on generic endpoints. So you would be able to configure them on "endpoint" and jms:endpoint" but not on "smtp:endpoint" for example. Ross: The approach with 2) would be to have a single element in mule.xsd which is used from each transport schema, there is no need to have transport specific XA transaction elements. See MULE-3382 .
          Show
          Dirk Olmes added a comment - http://fisheye.codehaus.org/changelog/mule/?cs=12416

            People

            • Assignee:
              Dirk Olmes
              Reporter:
              Andrew Perepelytsya
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 6 hours
                6h
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 3 hours, 30 minutes Time Not Required
                3h 30m

                  Development