Решение с длительным временем транзакции для Java EE? - PullRequest
Новая
       19

Решение с длительным временем транзакции для Java EE?

4 голосов
/ 17 ноября 2008

Проблема, с которой я несколько раз сталкивался в своей карьере, заключается в многоуровневой архитектуре обслуживания, когда одна нисходящая система может привести к выходу из строя всего клиентского приложения, если оно перейдет в состояние, когда все его потоки задействованы в тупике или в каком-либо другом виде. ошибки бесконечного цикла в этой системе. В этих условиях сокет сервера на сервере Java EE все еще принимает и ставит в очередь запросы от клиентских приложений. Это приводит к тому, что клиентское приложение использует все свои потоки, ожидая ответов от правильно установленных соединений сокетов. Затем все пользователи блокируются из системы, поскольку их запросы также находятся в очереди.

Я подумал о нескольких решениях, но мне было интересно, есть ли у сообщества лучшие решения.

  1. Изолированные пулы потоков для последующих запросов. Это становится проблемой, потому что вы объединяете количество незанятых потоков в вашей системе, создавая множество небольших пулов, которым необходимо иметь достаточно потоков для обеспечения полной пропускной способности. Появление потоков означает, что вам нужно разобраться с условиями транзакций и безопасности самостоятельно. На самом деле не поддерживается Java EE.

  2. Решение MDB, предпочтительное асинхронное решение для Java EE, однако оно кажется довольно тяжелым, но дает дополнительное преимущество, позволяя серверу приложений иметь дело с управлением пулами потоков MDB. (В настоящее время номер один в моем списке)

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

У вас, ребята, есть идеи получше?

Ответы [ 3 ]

1 голос
/ 17 ноября 2008

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

Ваше предложение (1) также можно выполнить в WebSphere или Weblogic с помощью обычного WorkManager. Это позволит вам создавать управляемые потоки в этих средах и довольно легкий.

API WorkManager и TimerManager

0 голосов
/ 03 июня 2009

Вы можете попробовать легкий подход MDB с Atomikos MessageDrivenContainers (управляемые сообщениями POJO). Ваше приложение будет более легким, лучше тестируемым и, вероятно, более масштабируемым.

См. http://www.atomikos.com/Publications/J2eeWithoutApplicationServer.

НТН

Guy

0 голосов
/ 17 ноября 2008

Мы используем MDB, где очередь сохраняется в базе данных, что дает преимущество в том, что сообщения не теряются, если система выходит из строя.

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

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

...