Отправка сообщений JMS и откат транзакций

Question

Мы создаем систему, которая будет отправлять сообщения из одного приложения в другое через JMS (используя Websphere MQ, если это имеет значение). Эти сообщения имеют форму «Создать х» или «Удалить х». (Конечным результатом этого является то, что сторонняя система должна быть проинформирована о сообщениях «Создать и удалить», поэтому конец чтения очереди JMS будет разговаривать с сторонней системой, в то время как конец записи JMS очередь просто передает сообщения, которые нужно обрабатывать)

Проблема, о которой мы беспокоимся, заключается в том, что одно из сообщений выходит из строя. Первоначальная мысль здесь состояла в том, чтобы просто откатить отказы в очереди JMS и позволить нормальному механизму повтора обрабатывать ее. Это работает до тех пор, пока вы не получите Delete, за которым следует Create для того же идентификатора, например.

• Удалить 123 - Сбой, откатывается на очереди
• Создать 123 - Удается
• Удалить 123 - Повторить от ранее отказа

Конечным результатом этого является то, что треть стороне было предложено создать 123, а затем сразу же удалить 123, а не наоборот.

Хотя это не идеальный вариант, из-за того, что я читал, кажется, что Message Affinity поможет здесь, чтобы мы могли гарантировать, что сообщения обрабатываются в правильном порядке. Тем не менее, я не уверен, как сближение сообщений будет работать, когда сообщения обрабатываются и не возвращаются в очередь? (Message Affinity обычно считается плохой идеей, но нагрузка здесь не будет большой, а риск появления ядовитых сообщений очень низок. Это просто риск, что сторонняя сторона, с которой мы взаимодействуем, имеет краткий что мы касаемся)

Если это не так, есть ли какие-либо мысли о том, как это сделать?

Редактировать - Дальнейшие осложнения. Система, которую мы собираемся интегрировать с третьей стороной, заключается в замене системы, которую они использовали от другого поставщика до недавнего времени. Таким образом, есть куча данных, которые уже есть у сторонних производителей, но, как оказалось, очень сложно получить это. (Третья сторона даже не отправляет сообщения об успешном/неудачном обращении, а просто подтверждение о получении!), Поэтому мы фактически не знаем начального состояния системы.

Answer 1

Единственный способ избежать описанного выше сценария - иметь различную классификацию сбоев сообщений; имея в виду, что ваше сообщение должно быть обработано в порядке (сродством сообщений)

Рассмотрим ситуацию: -.

Если приложение получает Удалить X, для которых он не получит Создать х перед тем, затем классифицировать это Сценарий ошибки как «Business Error», так как эта ошибка возникла из-за того, что Производитель сообщения отправил неправильное сообщение. Или мы можем сказать, что Продюсер сообщения отправил сообщение в неправильном порядке.

После того как вы классифицируете эту ошибку как «Business Error», вы не должны называть откаты; вместо этого вставьте это сообщение в базу данных с «Ошибка бизнеса» в качестве идентификации.

Таким образом, вы передали это сообщение из очереди и снизили риск отката и еще больше снизили риск несогласованного поведения вашего приложения.

Теперь рассмотрим другой сценарий: -

Если само приложение имеет некоторые проблемы, (например, базы данных или веб-сервер идет вниз или любая такая техническая ошибка), то в этом случае используется Откат механизм очереди JMS и Оцените эту ошибку как «Technical Error».

Так что, если какой-либо «Technical Error» произошло, JMS Queue будет повторять сообщение до тех пор пока ваше приложение может принимать и обрабатывать их.

После того, как ваше приложение вставлено после этого «Technical Error» и попыталось обработать сообщения в последовательном порядке, то же самое правило применяется здесь, то есть если произошла «Ошибка бизнеса», тогда это сообщение больше не будет повторено.

Примечание: «Экспертная ошибка» классификации должны быть согласованы все стороны, то есть, если вы маркировкой любого сообщения, как «Business Error» это не означает, что это сообщение уже не полезно, и ваш продюсер должен отправлен новый «Удалить х» для любого Действителен «Создать х».

Некоторые из „Бизнес Ошибка“ вы можете взять на счета are--

1. Полученное „Удалить х“ перед „Создать х“

2. Полученный «Создать х» после «Создать х»

3. Received «Удалить х» после того, как действуют «Удалить х»

Answer 2

Точный способ решения этого является включение в сообщении последовательность, в которой предыдущее сообщение не может перезаписать более поздний.

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

Позже банки начали транзакции с записью в течение дня, а затем отсортировали их в порядке, наиболее выгодном для банка до их обработки. Например, если самые крупные проверки были очищены в первую очередь, а в счете закончились деньги, несколько небольших проверок могут отскочить, создав несколько сборов за банкротство банка. Как только это было обнаружено, чтобы стать широко распространенной практикой, оно было изменено, чтобы всегда применять транзакции в порядке, наиболее благоприятном для владельца учетной записи. (По крайней мере, здесь, в США.)

Это распространенная проблема, и она была решена много раз, первая из них была десятилетиями назад. Там на самом деле нет никакого оправдания больше для приложения корпоративного класса для обеих сторон

1. Использование асинхронного обмена сообщениями, в которых порядок доставки дизайн не может быть гарантирована, и
2. содержат характеристическую зависимость от доставки заказа, чтобы гарантировать целостность из транзакций и данных.

Упоминание об аффинности сообщений намекает на решение этого вопроса при приближении к транспортной проблеме. Для того, чтобы гарантировать доставку заказа сообщений необходимо следующее:

• Один и только один отправитель сообщений
• Один и только один узел, из которого отправляются сообщения.
• Один и только один путь между отправителем и получателем сообщений.
• Одна и только одна очередь, в которой принимаются сообщения.
• Все сообщения обрабатываются под синхронизацией.
• Возможность обрабатывать любые сообщения, пока существует сиротская транзакция (обработка исключений соединений).
• Нет очереди резервного копирования на входной очереди.
• Нет DLQ, если сообщения проходят по каналу.
• Использование приоритета в любой очереди по пути.
• Один и только один приемник сообщений.
• Отсутствует возможность масштабирования приложения, кроме добавления ЦП и памяти к узлу (узлам), на котором размещаются QMgr (s).

Или проблема может быть решена в дизайне приложения с использованием заметок, компенсационных транзакций или любых других методов, обычно используемых для устранения зависимостей последовательностей.

(примечание: Если рассматриваемая заявка является готовым пакетом поставщиков, мне кажется, что я создаю проблему доверия. Ни одно приложение не может претендовать на надежность, если что-то настолько обычное, как резервное сообщение может испортить целостность данных.)