使用 JMS 队列的潜在陷阱？

我被要求设计和实现一个系统，用于从大量设备接收大量自动传感器数据。此数据将定期生成，并在 http 帖子中以 xml 形式发送到服务器。如果设备没有收到来自服务器的特定确认，它们将继续重新发送相同的数据。在通过事务将此数据插入到主数据库中的许多表中之前，需要对此数据进行一些潜在的繁重处理，此外，还需要将某些数据点排队以重定向到其他外部URL。

我计划使用带有servlet的Java应用程序服务器（倾向于GlassFish）来接收传入的数据。我想实现某种排队机制来临时存储数据，以便对传感器的响应不依赖于所有中间处理。单独的独立队列也是数据重定向部分的要求。在做了一些研究之后，两个主要的选择似乎是：

1） 在应用服务器上安装数据库，并对各种队列使用表。队列将由 Java 应用程序处理，这些应用程序可以在应用程序服务器中运行，也可以作为其自己的服务独立运行。

2） 使用数据库支持的 JMS 解决方案来实现队列。

我对JMS并不熟悉，但从我所读到的内容来看，在这种情况下，它似乎是更好的解决方案。主要要求是，在处理之前，不会丢失任何传感器数据或从队列中删除任何传感器数据，并且或多或少地按顺序处理这些数据。我们还希望能够轻松地在特定时间停止某些队列的处理，但仍要让它们累积数据，并使这些消息永不自动过期。

对于策略 1，我很清楚如何满足这些要求，但它可能不如策略 2 健壮和可扩展，而且开发起来更复杂，因为我需要编写自己的多线程代码来处理各种独立队列。我想知道为此目的使用JMS队列可能有什么潜在的陷阱，因为我以前从未使用过它们。

数据完整性是一个大问题，所以我需要确保JMS在服务器重新启动，断电或队列由于某种原因变得非常大的情况下可以保证不会丢失数据。例如，在一段时间内完成对主数据库的事务的问题是否可能导致JVM内存不足，崩溃并丢失所有累积的数据？（这将是噩梦般的场景）。

另外，我想知道是否有任何方法可以通过应用程序服务器管理工具暂停JMS队列处理，或者轻松查看队列中的内容（我将对一个对象进行排队，该对象将是消息xml加上一些其他数据，包括收到的时间戳等）。我在这里阅读了一些涉及相关问题的帖子，但希望获得一些直接的反馈。基本上，我想知道JMS不是合适的排队解决方案的实例（如果有的话），以及这是否是其中一种情况。任何建议都非常感谢。