с точки зрения обработки сообщений из очередей или тем (JMS) существуют такие известные опции, как: автоматическое подтверждение, подтверждение клиента, транзакция.
Я всегда предпочитаю транзакции, однако склоняюсь к использованию стандартного механизма отката поддерживается большинством промежуточного программного обеспечения для обмена сообщениями. Это означает, что если какая-либо ошибка / исключение возникает во время фазы использования и обработки сообщения, сообщение не теряется и сохраняется в исходной очереди. Кроме того, Spring изменил значения по умолчанию на transacted Подтверждение.
Однако, исходя из спецификации JMS, хорошее письменное приложение или прослушиватель сообщений всегда должны делать максимум с точки зрения обработки исключений и в журнале обработчика ошибок * 1024. * он должен отлавливать практически большинство исключений, связанных с приложением / данными, и каким-то образом обрабатывать эти случаи в соответствии с требованиями. Это будет означать только серьезные проблемы с инфраструктурой, такие как память / процесс cra sh et c. должен привести к откату транзакции и, таким образом, к сохранению сообщения в очереди. Является ли это правильным и обычно рекомендуемым?
Теперь, каковы варианты и лучший рекомендуемый подход к обработке сообщений, который также включает взаимодействие с базой данных и вторым получателем JMS? XA или глобальные транзакции, которые мы можем сразу игнорировать.
Я все еще думаю, достаточно ли просто обработки обработки в локальной транзакции, управляемой JmsPlatformTransactionManager ... В этом случае БД обновляется, даже если несколько Операции на транзакцию, могут выполняться с использованием автоматической фиксации или во вложенной или новой транзакции, что приводит к записи в БД "все или ничего". Также возможные взаимодействия с другим назначением JMS (например, публикация хранимых данных) и в транзакции обработки сообщений могут быть выполнены вне транзакции или вложенной транзакции или внутри ее собственной.
Конечно, оптимальный и желательный случай - сделать обработку простой и полностью функциональной, чтобы мы не оставались в несогласованном состоянии, когда что-то хранится, но публикуется не все или что-то, но не все и т. Д. c.
Есть ли здесь какая-то закономерность? В микросервисной архитектуре все это происходит в рамках одного сервиса. Лучше ли как-то разорвать поток и просто иметь ссылки в базе данных, используя которые мы можем определить, какая часть должна быть повторно обработана, используя некоторые запланированные действия и т. Д. c.?
С транзакциями весь поток может быть просто повторно выполнен, но, поскольку он охватывает 3 ресурса, также возникают некоторые трудности.
Надеюсь, я описал это, чтобы его можно было понять ... если нет, я не смогу уточнить :)