私の Web アプリには、常に多くのメッセージを受信する JMS トピックがあります。メッセージを処理し、メッセージ データに基づいてデータベースを更新する MDB があります。org.hibernate.exception.LockAcquisitionExceptionトピックが複数のメッセージを同時に受信しているときに取得していたので、MDB の maxSessions 属性を 1 に変更してシングルトンにしました。
現在、Hibernate の例外は表示されなくなりましたが、パフォーマンスに懸念があります。問題が発生する前に、トピックがどれくらい大きくなると予想できますか? JBoss 4.3 EAP を使用しており、これを設定する方法を検索しようとしましたが、何も見つかりませんでした。Java がメモリ不足になるまでトピックのサイズは大きくなりますか、それとも JBoss で設定できるものですか?
By default, JBoss Messaging will store its messages in an embedded Hypersonic database. If your topic starts filling up, your memory consumption shouldn't increase linearly, but sooner or later the database will fill up (from what I recall, Hypersonic has a 40,000 row limit, in this configuration at least).
More generally, if you're producing messages faster than you're consuming them, then you have a problem. You either need to produce them more slowly, consumer them more quickly, or work out a way of discarding messages.
JMS トピックでキューに入れることができるメッセージの数は?
使用可能なメモリまたはディスク容量に依存し、JMS ベンダーとキュー構成に依存します。
ただし、データベースへの更新の純粋なパフォーマンスに関しては、バッチ処理を行う必要があります。（スレッドが1つしかない場合でも）。X メッセージを一度に取得してすべて処理し、同じトランザクションを使用してバッチ更新をデータベースに送信します。データベースが 1 行とほぼ同じ時間で 100 行または 1000 行を更新/更新できる可能性があります。
余談ですが、パフォーマンスはまったく気にしていませんか？今は遅すぎませんか？