JMS Message Bridging – SwiftMQ – Weblogic JMS

Found this really useful link on swift MQ website…




Implementing sequencing solutions with OSB when using JMS messaging

I Came across this post when I was looking for option on how to implement sequencing solutions with OSB when using messaging (JMS) Which talks about Using Message Unit-of-Order with JMS


Using Message Unit-of-Order

Message Unit-of-Order is a WebLogic Server value-added feature that enables a stand-alone message producer, or a group of producers acting as one, to group messages into a single unit with respect to the processing order. This single unit is called a Unit-of-Order and requires that all messages from that unit be processed sequentially in the order they were created.

Oracle documentation

Doesn’t give us an as is solution but is definitely worth exploring on these lines…

Youtube Video presentation

Other references

Watch this space for updates on how I get on with this.



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.