Much awaited transaction management feature in Oracle Service Bus (OSB) message flows has been incorporated in the latest Oracle Service Bus release (OSB 11g). Now every OSB proxy service comes with two additional configuration parameters (check boxes) “Transaction Required” and “Same Transaction for Response” to deal with the transaction requirements.
Transaction Required, selecting this option ensures OSB execute the proxy service message flow in the context of a transaction. If a global transaction already exists, the transport provider propagates it in the request. If no global transaction exists, the message flow run time starts a new transaction. If the message flow run time starts a new transaction, the transaction-context begins before the service configuration is validated or run (for example, security checking or WS-I validation), and before message flow execution, ensuring that all processing and execution occurs in the transaction context.
If the message flow run time starts a transaction, quality of service (QoS) is exactly-once. However, if Service Callouts or Publish actions have the outbound QoS parameter set to best-effort, OSB executes those actions outside of the transaction context. To have OSB execute those actions in the same request transaction context, QoS on those actions need to be set to exactly-once. The service maintains its original messaging pattern (synchronous, asynchronous, one-way) regardless of the setting on this option.
This configuration has a catch; On selecting this option OSB invokes the system error handler for all failed transactions. Failed transactions cannot be catch in a user-configured error handler. For synchronous patterns, a transaction-exception is returned through the response. For asynchronous patterns, where the transaction is designed to be committed in the request, the exception is sent back on the request thread. Note that in asynchronous patterns, an error in the response that occurs after transaction committal in the request does not affect the transaction.
Another transactional configuration parameter is Same Transaction for Response, If the transaction of the request thread need to be propagated to the response thread this option also needs to be selected. On selecting this option, the message pattern becomes synchronous automatically, regardless of the initial message pattern setting.
Some do and don't while implementing OSB transaction options.
Always define the transaction timeouts for global transactions. Before setting the transaction timeout make sure that the timeout is sufficient to complete the message flow.
For those business requirements where request required transaction committal before sending the response, such as in a one-way, asynchronous pattern do not select Same Transaction for Response option. Selecting Same Transaction for Response option will override the pattern to synchronous.
For making non-business interactions call (such as logging/message tracking services call) within a transactional flows set QoS to best effort. This will make the services to call outside the transaction on an event of their failure the main transaction will not be affected.
Always define the transaction timeouts for global transactions. Before setting the transaction timeout make sure that the timeout is sufficient to complete the message flow.
For those business requirements where request required transaction committal before sending the response, such as in a one-way, asynchronous pattern do not select Same Transaction for Response option. Selecting Same Transaction for Response option will override the pattern to synchronous.
For making non-business interactions call (such as logging/message tracking services call) within a transactional flows set QoS to best effort. This will make the services to call outside the transaction on an event of their failure the main transaction will not be affected.
