Доброго времени суток.

Третий день копаюсь в JMS. Прочитал не один туториал, спецификацию, побегал по форумам, но внятного ответа на свой вопрос так и не нашёл.

Как известно, jms работает следующими образом:

Продюсер посылает сообщение (вне трансакции), сервер принимает его и подтверждает, после чего send разблокируется. Теперь представим, что во время этой процедуры обрывается соединение клиент-сервер. А произойти это может, когда

- сообщение летит на сервер (т.е. не достигает его)
- подтверждение летит к клиенту (клиент не получил подтверждение, но сообщение лежит на сервере)

В обоих случаях, клиент поучает JMSException, что сигнализирует об ошибки.
Так вот, вопрос: Как различить эти две ситуации? Как и что для этот следует настроить? Послать сообщение ещё раз может привести к двухразовой его обработки. Не послать его вовсе - тоже не выход. 

Гарантирует ли jms одноразовой, 100% доставки сообщения?

 “Полную гарантию может дать только страховой полис”  (с)  О. Бендер

А если серьезно, то в тонкостях этих ситуаций разбираться незачем. Снабдите свои сообщения уникальным идентификатором.
Если producer получил JMSException при отправке, то он просто перепосылает сообщение. Consumer в свою очередь должен игнорировать сообщения, id которых он уже видел.

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

Если я правильно понял, то речь идет о шаблоне TransactionalClient

Пример из книги EIP:

Вот что говорит спецификация (4.4.13 Duplicate Production of Messages) по этому поводу:

If a failure occurs between the time a client commits its work on a Session and the commit method returns, the client cannot determine if the transaction was committed or rolled back. The same ambiguity exists when a failure occurs between the non-transactional send of a PERSISTENT message and the return from the sending method.

It is up to a JMS application to deal with this ambiguity. In some cases, this may cause a client to produce functionally duplicate messages.
A message that is redelivered due to session recovery is not considered a duplicate message.

То бишь, отправитель не в состоянии различить эти две ситуации...

Всем спасибо.

Это сообщение отредактировал(а) LeoGL - 4.10.2012, 15:21