Azure Не ясна поддержка транзакций JMS ServiceBus

Question

Я работаю над Java приложением JMS, подключающимся к Azure ServiceBus. Как только я узнал, что JMS поддерживается, я не ожидал никаких проблем. Однако, когда я начал создавать соединения и добавил Spring JmsTransactionManager, я получил ошибку, в которой говорилось, что моя подписка Azure имеет базовый уровень, и поэтому транзакции не поддерживаются. Я обновился до уровня «Стандарт», и ошибка была устранена. Это покрыто здесь .

Однако во время тестирования я не был уверен, что он работает должным образом, и я тестирую поведение, и в то же время меня смутила другая документация MS о том, что "транзакционные сеансы" не поддерживаются в этом протоколе JMS через AMQP.

Вопрос:

1. Можно ли рассчитывать, что очередь в служебной шине будет передаваться, что означает сообщение не будет удалено из очереди, пока мой менеджер транзакций явно не вызовет COMMIT?

2. Как можно требовать соблюдения JMS, но в то же время сказать, что я не поддерживаю транзакционные сеансы.

Спасибо за любой ответ, потому что я в замешательстве.

Обновление:

У стартера Azure Service Bus для Spring Boot есть Qpid в качестве зависимости вот что я использую под капотом - я не знал об этом первым:

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

Answer 1

В настоящее время не существует спецификации для распределенных (XA) транзакций через AMQP, и поэтому клиент Qpid JMS не предлагает реализацию XA ConnectionFactory, поэтому, если вы используете это, то наверняка не получите никакой поддержки для распределенных транзакций.

Сам Jp-клиент Qpid реализует локальные транзакции, поэтому в этом смысле вы можете использовать стандартный сеанс JMS локальных транзакций, но вполне возможно, что MS отключила это с помощью пружинных загрузочных битов, чтобы отговорить людей от его использования в качестве польза от локальных транзакций довольно мала, особенно для людей, использующих Spring, которые могут подумать, что они участвуют в более крупных распределенных транзакциях, хотя на самом деле это не так.