Transaction handling in Oracle Service Bus

The way transactions are handled depends on the nature of incoming request and the transaction characteristics of the partner service.

Transactional Binding

If the incoming binding for the request to OSB is transactional then the proxy will participate in that txn and any proxy/business svc invoked by this proxy will participate in the same txn.

The control of this transaction will be with the client.

If the service inturn invokes several transactional proxies/business svc’s they will be all enrolled in the intial inbound txn and committed together or rolled back together.

Non Transactional Binding

while if the incoming binding for req is non transactional eg SOAP or file transport then the txn behaviour will depend on type of proxy.

There is a difference between types of proxies available in OSB 11g than the previous versions.

Non-Transational proxy (default type and the only type that existed prior to 11g)

Unless there are incoming transactions, the proxy will not execute as part of a transaction.

Any subsequent transactional services it invokes will each execute in their own txn.

i.e. they will not necessarily be all complete or roll back together. some may succeed while others may not.

Transational proxy (A new feature in 11g)

It will initiate a new txn if one does exist in the req recieved, and there on all calls are part of the same txn, hence all commit or roll back together.

You can configure transactions behaviour of a proxy service in the message handling tab of the proxy service.
See the below Oracle documentation on this.

To create or edit…

Transaction Required

Select this option to ensure Oracle Service Bus executes 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 (even if you do not select this option). If no global transaction exists, the message flow run time starts a transaction. If the message flow run time starts a 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 is exactly-once. However, if Service Callouts or Publish actions have the outbound quality of service parameter set to best-effort (the default), Oracle Service Bus executes those actions outside of the transaction context. To have Oracle Service Bus execute those actions in the same request transaction context, set quality of service on those actions to exactly-once.

The service maintains its messaging pattern (synchronous, asynchronous, one-way) regardless of the setting on this option.

For transaction timeouts, the global transaction timeout value configured in the Oracle WebLogic Server Console applies.

Exceptions in Transactions

Oracle Service Bus invokes the system error handler for failed transactions. You cannot catch failed transaction exceptions 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.

Same Transaction for Response

This option applies only to one-way and asynchronous messaging patterns.If you select this option, Oracle Service Bus propagates the transaction context from the request thread to the response thread.

If you select this option, the message pattern becomes synchronous automatically, regardless of the initial message pattern setting (such as asynchronous or one-way).

You would not use this option, for example, if the business service in the request required a transaction committal before sending the response, such as in a one-way pattern.

For transaction timeouts, the global transaction timeout value configured in the Oracle WebLogic Server Console applies.


  1. ALSB / OSB do not provide transaction capabilities. It provides implicit transaction which means if back-end business service is participating in the transaction ALSB will simply join the same transaction as suppose to starting its own. Hope this is clear.

  2. Thanks for your comments Sanjeev, I know there is nothing out of the box in OSB but I am trying to figure out the best possible work around in a scenario where your request is initiated via some osb proxy service.

    Do you have any example which shows this capability..

  3. Hi Nitin, Sorry for the delayed response. I don’t have example but I worked in a projects where both stateless and transactions calls are made via OSB.
    In transaction calls we used JMS. so this provides guarantee delivery and reliability etc.,, and provides transaction hook-up.
    I am not sure if this is clear , if not drop me an email and will walk you through the scenario and can discuss more.

    BTW, you are covering some good stuff with regards to OSB / Oracle 11g. Good work and keep it up.

  4. Transaction is managed in OSB through Service Callouts. Request-Response criteria in service callout make sure that unless response is received from the service transaction is not complete and would be aborted in case of errors.
    We can use ‘reply with success’ in case we would like to abort the transaction. Also calling one proxy as local proxy by parent proxy maintains the transaction and is stateful. In case of proxies based on http/jms, transaction can be maintained by reliable storing the data in JMS on weblogic server.

  5. Hi Rajneesh,

    Thanks for your inputs, Are you refering to 11g ? My concern was mainly regarding managing transactions on Queues when you initiate them from the OSB. eg. calling a BPM process and making sure that the input request is not lost incase there is an error in the BPM process or other dependent resources. Or you can say Asynchronous calls to resources outside OSB.

    Also “reply with success” will abort the transaction but does not ensure that success of the transaction.

  6. one small clarification.
    we have scenario where we have osb calls to a bpel and bpel has webservices and intern webservice is calling to java object and it calls internally hibernate.

    so how in osb level we can handle transaction…..any idea will be appricated

  7. @Susant : As i’ve described in the post. The OSB can initiate a transactional service using a transactional proxy and then any subsequent calls will be part of that transaction.

    In your case you pass the control to bpel and then to java which will then have to take care of the transaction.
    In order to ensure that all the invocations are part of the same transaction you have to make sure that the transaction is propagated to the services you are dependent on.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s