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