JavaDude
JavaDude

Reputation: 165

Azure ServiceBus JMS transaction support not clear

I'm working on Java JMS application connecting to Azure ServiceBus. Once I found out JMS is supported I did not expect any problems. However, when I started creating the connections and added Spring JmsTransactionManager I got an error which said my Azure subscription is "Base" tier and thus transactions are not supported. What I did was upgrading to "Standard" tier and the error was resolved. This is covered here.

However during testing I was not sure it is working as expected and I'm testing the behavior and in the meantime I got confused by another MS documentation saying "transacted sessions" are not supported in this JMS over AMQP protocol.

Question:

  1. Can I rely the queue in Service bus will be transacted meaning the message won't be removed from queue until my transaction manager explicitly calls COMMIT?

  2. How can anyone claim JMS compliance but at the same time say I don't support transacted sessions.

Thank you for any response because I'm confused.

Update:

The Azure Service Bus starter for Spring Boot has Qpid as dependency so that is what I'm using under the hood - I was not aware of this first:

<!--Qpid-->
<dependency>
    <groupId>org.apache.qpid</groupId>
    <artifactId>qpid-jms-client</artifactId>
</dependency>

Upvotes: 1

Views: 1707

Answers (1)

Tim Bish
Tim Bish

Reputation: 18356

There is not currently a specification for distributed (XA) transactions over AMQP and as such the Qpid JMS client does not offer an XA ConnectionFactory implementation so if you are using that then for sure you would not get any support for distributed transactions.

The Qpid JMS client itself does implement local transactions so in that sense you could use a standard locally transaction JMS session but it is possible that MS has disabled that through the spring boot bits to dissuade folks from using it as the benefit of local transactions is quite small especially for folks using spring how might think that they are participating in a larger distributed transaction when they are in fact not.

Upvotes: 1

Related Questions