Использование транзакций с JMS (ActiveMQ)

Question

В нашем бэкэнде есть несколько сервисов, которые отправляют и получают сообщения через JMS с Apache ActiveMQ.Каждый сервис имеет один сеанс с брокером ActiveMQ.Теперь мы хотим сделать следующее (псевдокод):

Сервис s1:

Message m = createMessage("s2","Hello World")
sendMessage(m)
try {
   Message answer = commit()
   ...
} catch (TransactionFailedException e){
   ...
}

Сервис s2:

onMessageReceive:
try {
   Message m = getReceivedMessage()
   Message answer = doSomeStuff()
   send(answer)
} (Exception e) {
   rollback()
}

Фиксация обязательно должна блокироваться до тех пор, покаответ приходит или транзакция не выполняется.Также должно быть возможно, что сервис s2 создает новую вложенную транзакцию, потому что s2 отправляет сообщение другому сервису.Как можно использовать транзакции из ActiveMQ для достижения такого поведения?Есть несколько доступных примеров, но в этих примерах транзакции просто используются как пакетный механизм для отправки сообщений.

Answer 1

Я интерпретирую ваш вопрос так, что вы хотите, чтобы сбой работы в s2 приводил к откату текущей транзакции в s1.

Итак, вы хотите

s1 do some work

s2 do some work

if ( s2 OK )
   perhaps do even more work in s1
   commit s1
else
   rollback s1

Асинхронная модель JMS классически не предназначена для этой цели.Основная причина в том, что

1. Во время транзакции ресурсы (например, записи базы данных) заблокированы - s1 проделал некоторую работу, пока транзакция не разрешена, эти ресурсы должны быть заблокированы.
2. Асинхронная обработка предназначена для отделения работы s2 от работы s1, работа s2 может происходить через много минут или даже дней после того, как запрос был помещен в очередь.S2 не может знать, ждет ли его еще s1.Весь замысел JMS состоит в том, чтобы отделить обработку в s1 и s2.

Существует два подхода к достижению координации между s1 и s2:

Один из них заключается в использовании истинно распределенных транзакций,используя протокол, отличный от JMS, например, EJB могут передавать транзакции из одного процесса в другой или использовать WS-AtomicTransaction и веб-сервисы.Это добавляет эксплуатационную сложность - вам необходимо управлять журналами транзакций и сценариями, в которых у вас есть долгосрочный сбой одного компонента.

Альтернативой является проектирование двух взаимодействующих систем для надежной обработки «компенсирующей» работы.Вы соглашаетесь с тем, что, например, s2 может завершиться сбоем и иметь вторичную обработку для обработки повторных запросов, работы с тайм-аутами и т. Д. В конце концов, вы можете столкнуться с некоторыми ситуациями, когда необходимо вмешательство людей, но с хорошим дизайном эти ситуации могут бытьминимален.В крупномасштабных системах зачастую нет альтернативы этому, например, система бронирования авиакомпании и система бронирования сети отелей вполне могут быть не рассчитаны на координацию распределенных транзакций, поэтому нет альтернативы тщательной обработке для управления бронированием авиабилетов и номеров.