Websphere Liberty : JMS Sessions don't work

Question

I am migrating EJB application from websphere 9.0 to Liberty. I am using the application server migration utility to help me with the migration. One of the listed issue is:

Answer 1

The JMS APIs provides methods for batching up multiple message sends and receives in a single transaction. These methods are intended for use in non-managed client environments. The way you do this is to create a transacted session (or JMSContext) and then call the commit or rollback methods.

In a managed environment the specification effectively says you can't do this and the transacted parameters be ignored. This is because if you do JMS work in a global transaction then the work needs to be coordinated with that transaction, so commit/rollback have no meaning.

The traditional WebSphere Application Server (for historic reasons), allows you to create a transacted JMS session and call commit and rollback outside of a global transaction (if you are inside it follows the spec mandated behaviour) when using IBM MQ.

The rule in question is looking for the creation of a transacted JMS session or JMSContext and reporting a possible issue.

If your code is running in a global transaction this is a false positive and you can ignore it. If you are running outside a global transaction and using the MQ JMS provider then you should review your code to do one of the following:

1. Move the code into a global transaction
2. Rewrite the code to stop relying on the commit/rollback methods

Answer 2

JMS sessions in general will work in Liberty. However, transacted JMS sessions won't work. Therefore, applications using transacted JMS sessions which are ported to Liberty will not work as expected.

A transacted JMS session allows a client to collect different JMS operations (e.g. sending and consuming messages) into a single unit of work that is committed or rolled back atomically.

To be clear, a transacted JMS session uses what is sometimes called a "local" transaction because the transaction only applies to the specific JMS session involved. This is in contrast to a "global" transaction (sometimes called a "JTA" or "XA" transaction) which can involve many different kinds of resources (e.g. JMS, JDBC, etc.) and whose commit and roll-back is atomic across all those resources.