Access Keys:
Skip to content (Access Key - 0)
Leave feedback
Leave feedback
Cancel    
Cancel   
 

Contents

Transaction demarcation documentation

Transaction demarcation provides the ability to execute a group of message processors within the same transaction. To use it just place all the transactional message processors inside a transactional element.

Both jms outbound endpoints will be executed within the same transaction, if one fails, no message will be disptached

Mule will auto-discover the type of the transaction (jms, jdbc, vm) by creating the transaction for the first transactional resource encountered


Using more than one type of transactional element inside transactional

If more than one type of transactional resource is present in the transactional element it will fail.

Before execution jdbc outbound endpoint mule will throw an exception since the type of transaction created is JMS and not JDBC

To be able to use another type of transactional element NOT_SUPPORTED action type must be used.

jdbc endpoint will be executed outside the transaction created by transactional element

Mule EE supports transaction demarcation for multi transactional resources. It support XA transactions and Multi transactions


How to join a transaction an existent transaction

With transaction demarcation there's two possible transaction actions:

  • ALWAYS_BEGIN: This is the default action. Mule will always begin a transaction if there's no action configured or action is ALWAYS_BEGIN.
  • BEGIN_OR_JOIN: In this case, if there's a transaction in context, mule will try to join it, but if there's no transaction, transactional element will create one.


Error handling with transactional element

Transaction demarcation will start a transaction and end it, no matter the result. So, to make it work properly will must handle any exception thrown within the transactional scope. To do that transactional element has its own exception strategy.

If no exception strategy is configured then the default one will be applied. See how to define the default exception strategy

If FailingMessageProcessor throws an exception then catch-exception-strategy will be executed so the message will be sent to a vm dead letter queue and then the transaction will be commmited