同じプロセスの異なるスレッドで実行したいと思いcms::MessageConsumer
ます。cms::MessageProducer
これを安全に行うにはどうすればよいですか?
安全性を保証するには、2つのcms::Connection
オブジェクトと2つのcms::Session
オブジェクト(それぞれ消費者と生産者用)があれば十分でしょうか?これは必要ですか?
このタイプの使用を妨げる静的ライブラリレベルのオブジェクト間で共有状態がありますか?
同じプロセスの異なるスレッドで実行したいと思いcms::MessageConsumer
ます。cms::MessageProducer
これを安全に行うにはどうすればよいですか?
安全性を保証するには、2つのcms::Connection
オブジェクトと2つのcms::Session
オブジェクト(それぞれ消費者と生産者用)があれば十分でしょうか?これは必要ですか?
このタイプの使用を妨げる静的ライブラリレベルのオブジェクト間で共有状態がありますか?
JMS v1.1仕様を読む必要があります。これは、複数のスレッドで使用するのに有効なオブジェクトとそうでないオブジェクトを明確に示しています。つまり、Session、MessageConsumer、およびMessageProducerは、スレッド間で共有するのは安全でないと見なされます。通常、可能な限りスレッドセーフにするように努めていますが、問題が発生する可能性のある方法は確かにあります。セッションには単一のディスパッチスレッドが含まれているため、各スレッドで単一のセッションを使用することをお勧めします。また、一般に、MessageConsumer / MessageProducerごとにセッションを使用することをお勧めします。つまり、多くのコンシューマーとのセッションでディスパッチスレッドを共有する必要があります。シナリオに応じてレイテンシーを下げることができる各コンシューマーにメッセージを送信するため。
私は、Tim Bishの回答を補足するために自分の質問に回答しています。これは、重要な情報を提供したものとして受け入れています。
http://activemq.apache.org/cms/cms-api-overview.htmlから
CMSとは何ですか?
CMS APIは、JavaのJMSAPIのC++の結果であり、ネットワーク全体に分散している、または同じマシン上にあるクライアントとの間でメッセージを送受信するために使用されます。CMSでは、JMS APIとの同等性を可能な限り維持するためにあらゆる試みを行い、JMS機能がJavaプログラミング言語自体の機能に強く依存している場合にのみ分岐しました。いくつかの違いはありますが、ほとんどはごくわずかであり、ほとんどの場合CMSはJMS仕様に準拠しているため、JMSがどのように機能するかをしっかりと把握することで、CMSの使用がはるかに簡単になります。
スレッドセーフについてJMS仕様は何と言っていますか?
ここから仕様をダウンロードします:http: //download.oracle.com/otndocs/jcp/7195-jms-1.1-fr-spec-oth-JSpec/
2.8マルチスレッドJMSでは、すべてのオブジェクトが同時使用をサポートしている必要があります。同時アクセスのサポートは通常、ある程度のオーバーヘッドと複雑さを追加するため、JMS設計では、マルチスレッドクライアントによって自然に共有されるオブジェクトへの同時アクセスの要件が制限されます。残りの部分は、一度に1つの論理制御スレッドからアクセスできるように設計されています。JMSは、セッションの同時使用を制限するいくつかの特定のルールを定義します。彼らは私たちが提示したよりもJMSの詳細についてのより多くの知識を必要とするので
表2-2同時使用をサポートするJMSオブジェクト
- 宛先:はい
- ConnectionFactory:はい
- 接続:はい
- セッション:いいえ
- メッセージプロデューサー:いいえ
- MessageConsumer:いいえ
この点については、後で説明します。ここでは、それらを課す理由を説明します。
セッションへの同時アクセスを制限する理由は2つあります。まず、セッションはトランザクションをサポートするJMSエンティティです。マルチスレッドのトランザクションを実装することは非常に困難です。次に、Sessionsは非同期メッセージの消費をサポートします。JMSでは、非同期メッセージの消費に使用されるクライアントコードが複数の同時メッセージを処理できる必要がないことが重要です。さらに、セッションが複数の非同期コンシューマーで設定されている場合、これらの個別のコンシューマーが同時に実行されている場合にクライアントが処理を強制されないことが重要です。これらの制限により、JMSは一般的なクライアントで使いやすくなります。より洗練されたクライアントは、複数のセッションを使用することで、必要な同時実行性を得ることができます。
私がJava側から知っている限り、接続はスレッドセーフです(そして作成するのにかなり費用がかかります)が、SessionとmessageProducerはスレッドセーフではありません。したがって、スレッドごとにセッションを作成する必要があるようです。