questioner,

это JMS 2.0: http://www.oracle.com/technetwork/articles/java/jms2messaging-1954190.html

questionerа в 1.1 что ?JMS 1.1 появился на свет 15 лет назад, ожидать чего-то толкового от стандарта 15-летней давности, на мой взгляд, не стоит. Вот то что ни spring-jms, ни ActiveMQ нифига JMS 2.0 не поддерживают - это реально беда.

questionerНо это похоже фишка ActiveMqВы определитесь что вам в итоге нужно. У вас есть 4 случая, которые получаются из комбинаций: сессия транзакционная/нетранзакционная, сообщения персистентные/неперсистентные. По приведенной вами ссылке на IBM MQ написано:

ibmFor messages sent in a transacted session, the application ultimately determines whether the queue manager has received the messages safely when it calls commit(). If an application sends persistent messages within a transacted session, and one or more of the messages are not received safely, the transaction fails to commit and produces an exception. However, if an application sends nonpersistent messages within a transacted session, and one or more of the messages are not received safely, the transaction commits successfully. The application does not receive any feedback that the nonpersistent messages did not arrive safely.Т.е. в случае транзакционной сессии доставилось все или не все опредетяется при вызове commit(), а что там происходит с промежуточными отправками осталось на откуп реализации (может оно вообще копит сообщения на клиенте а потом при commit() высылает всю пачку - здесь я утрирую, поскольку нужно более вдумчиво читать спецификацию, но идея должна быть понятна). Дальше для IBM MQ разобран случай с неперсистентными сообщениями для нетранзакционной сессии (персистентные сообщения для нетранзакционной сессии не описаны):

ibmFor nonpersistent messages sent in a session that is not transacted, the SENDCHECKCOUNT property of the ConnectionFactory object specifies how many messages are to be sent, before IBM MQ classes for JMS checks that the queue manager has received the messages safely. If a check discovers that one or more messages were not received safely, and the application has registered an exception listener with the connection, IBM MQ classes for JMS calls the onException() method of the exception listener to pass a JMS exception to the application .здесь описан javax.jms.CompletionListener из JMS 2.0.

Для ActiveMQ описано суть то же самое:

ActiveMQThe good news is that ActiveMQ sends message in async mode by default in several cases. It is only in cases where the JMS specification required the use of sync sending that we default to sync sending. The cases that we are forced to send in sync mode are when persistent messages are being sent outside of a transaction.Т.е. в случае транзакционной сессии оно изначально оптимизировано, потому что здесь важен commit(). А дальше кейс про персистентные сообщения для нетранзакционной сессии, который для IBM MQ не описан:
ibmIf you are not using transactions and are sending persistent messages, then each send is synch and blocks until the broker has sent back an acknowledgement to the producer that the message has been safely persisted to disk. This ack provides that guarantee that the message will not be lost but it also costs a huge latency penalty since the client is blocked. Many high performance applications are designed to be tolerate a small amount of message loss in failure scenarios. If your application has been designed in this fashion, you can enable the use of async sends to increase throughput even when using persistent messages.По факту написано: ну если вы хотите забить на подтверждения, то вот вам опция, а дальше выкручивайтесь как хотите, никаких javax.jms.CompletionListener здесь нет, потому что это не JMS 2.0.