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

Details

  • User impact:
    High
  • Effort points:
    0.5
  • Similar Issues:
    None

Description

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

Issue Links

blocks

Sub-task - The sub-task of the issue MULE-2734 Error registering bean with name 'jdbcConnector' defined in null in XABridgeJmsJdbcTestCase

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Sub-task - The sub-task of the issue MULE-2736 JDBC transaction test hangs

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MULE-3322 JDBC transport ignores endpoint transaction properties

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MULE-3574 Resolve outstanding transaction issues/bugs

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. MULE-3340 There's no vm:transaction element in the VM schema

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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:
  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.
Hide
Permalink
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
Permalink
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.

People

  • Assignee:
    Dirk Olmes
    Reporter:
    Andrew Perepelytsya
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:

Time Tracking

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