Потенциальные ловушки в использовании очереди JMS?

Меня спросили к разработке и реализации систему для получения большого объема автоматизированных данных датчика из большого количества устройств. Эти данные будут произведены равномерно и отправлены на сервер как xml в сообщении http. Устройства будут продолжать снова посылать те же данные, если они не получат определенное подтверждение от сервера. Некоторая потенциально усиленная обработка этих данных должна будет произойти, прежде чем это будет вставлено во многие таблицы в основной базе данных через транзакцию, и дополнительно некоторые точки данных должны будут ставиться в очередь, чтобы быть перенаправленными к другим внешним URL.

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

1) Установите базу данных по серверу приложений и используйте таблицы для различных очередей. Очереди были бы обработаны JAVA-приложением, или работающим в сервере приложений или автономные как свой собственный сервис.

2) Используйте базу данных поддержанное решение JMS реализовать организацию очередей.

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

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

Целостность данных является большой проблемой, таким образом, я должен удостовериться, что JMS не может гарантировать потерю данных в случае перезагрузки сервера, перебоя в питании, или если очередь становится очень многочисленной по некоторым причинам. Например, мог проблема, завершающая транзакции к основной базе данных сроком на время потенциально, заставляет JVM исчерпывать память, отказывать и терять все накопленные данные? (Это было бы сценарием кошмара).

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