Public Forum Thread
Provides the ability to demarcate a transaction for a group of message processors
- Using service style configuration in mule a transactional context can be created by using transactional configuration in outbound routers. With flows, users have lost this power. The idea of this new feature is to restore that power and even make it better by providing a way to demarcate transactions for any group of message processors.
- Very common use case not supported by flows
- Not having a transactional context for outbound endpoints impede users to move from services to flow configuration style
- Cloud Connectors currently must support transaction configuration in not transactional inbound endpoint to avoid this problem
- SAP transport couldn't be developed as a cloud connector because of this limitation
Story: As a user I want to be able to define a transactional context for a set of message processors
A legacy system creates files with information about sales orders in a shared folder. For each sales order I must create a billing order and a production order. Each order is managed by a different system that will consume them from jms queues. Processing sales orders must prevent the creation of a billing order without a production order and vice versa. If processing fails then two error messages should be sent. One to a jms dlq and another to a ftp sales error folder and the original sales order file should be consumed.
Usages of transactional element
Element transactional allows demarcation of transactions. The reason why transaction demarcation has error handling is because each transaction must define a mechanism to resolve transaction in case of a failure.
Element transactional will support three kind of transaction propagation through the action attribute:
- ALWAYS_BEGIN: to start a transaction and resolve any previous transaction before transactional element
- BEGIN_OR_JOIN: to start a transaction if there's no transaction in context or join the transaction if there's already one in context.
There's no need to support following actions:
- ALWAYS_JOIN: Can already be don using <x:transaction action="ALWAYS_JOIN"/> in each endpoint
- JOIN_IF_POSSIBLE: Can already be don using <x:transaction action="JOIN_IF_POSSIBLE"/> in each endpoint
- NONE: Makes no sense. It resolves any transaction and this can already be done using <x:transaction action="NONE"/> in any endpoint.
To start a transaction the only requirement is to enclose each transactional message processor in a transactional element
Mule will auto-discover the type of the transaction (jms, jdbc, etc) by creating the transaction for the first transactional resource encountered
If the users want to define a transactional context that can create or join an existent transaction then the action attribute can be used:
In case that inside the transactional element another transactional resource is being executed Mule will fail to notice the user that the second transactional resource will not participate in the transaction
To allow this scenario a new transaction propagation action has been defined that must be configured explicitly:
More than one transactional resource type in transactional element can be supported using xa or multi-tx transactions: multi-tx:transactional and xa:transactional
No much risk. Whole field is prepared to include this feature by the changes done for exception - architecture clean up.
- Transactional context will be created as any other scope
- Users won't need to define any transaction configuration in the endpoints defined inside transactional element. Just placing an element inside transactional will make them to be in the same transaction.
- Potentially users will be able to select a group of message processors and mark them as transactional and studio can add the required transactional element
None. New functionality
Reorganization of Mule transaction management will be required. Add transactional scope documentation.