У нас есть сценарий, в котором после обработки входящего сообщения A с помощью управляемого сообщениями компонента мы записываем последующее сообщение B в другую очередь.Мы используем Glassfish 3.1.
Одной из целей в этом случае является то, что отправка сообщения B может происходить асинхронно и не должна быть надежной - то есть, если после обработки сообщения A мы попытаемся опубликовать сообщение B и онопроисходит сбой, мы не откатываем обработку для сообщения A.
Вторая цель состоит в том, что публикация сообщения B не должна блокировать или расширять область транзакции, охватывающей сообщение A. Мы хотели бы, чтобы транзакция, охватывающая сообщение A,быть закрытым как можно скорее и не оставаться открытым, пока обрабатывается сообщение B.
Одна из идей состоит в том, чтобы создать специальный EJB с методом, помеченным для этой цели @Asynchronous, и искать и вызывать этот EJB вконец onMessage ().Однако мы не уверены, является ли это наилучшей практикой в этом случае.
Мы не заинтересованы в создании дополнительного решения для оркестрации (например, ESB), которое бы обрабатывало этот и более сложные случаи.