私たちの EMS コードへの接続は、最初は適切に設計されておらず、リッスンするトピックごとに 1 つの TopicConnection オブジェクトを作成しました。したがって、実際には、トピックをサブスクライブするたびに、新しい接続、新しいセッション、そして最後に新しいリスナーを作成します。
シングル接続モデルに切り替えたい。1 つの接続オブジェクトを共有し、トピックごとに新しいセッション オブジェクトを作成することで、コードでこれを簡単に行うことができますが、これがコードなしで問題を引き起こすかどうかはわかりません。
私の理解では、Tibco EMS クライアント ライブラリは、接続の共有に関してスレッド セーフです。実際には、接続は単なるパイプであり、セッションはスレッド セーフな方法でこのパイプを再利用できます。
この仮定は正しいですか、それともこれ以上のことはありますか?
.NET EMS API はJMSに基づいています。JMS では、Connection オブジェクトと Session オブジェクトはスレッドセーフであると指定されており、プログラム内で再利用できます。Connection オブジェクトが単に EMS サーバーへのネットワーク パイプを表しているという点で、あなたの言うとおりです。EMS ユーザーズ ガイドには、次のように記載されています。
接続はかなり重いオブジェクトであるため、ほとんどのクライアントは接続を一度作成すると、クライアントが終了するまで開いたままにします。必要に応じて、アプリケーションで複数の接続を作成できます。
そしてセッションに関して：
セッションは、メッセージを生成または消費するためのシングルスレッド コンテキストです。Session オブジェクトを使用してメッセージ プロデューサまたはメッセージ コンシューマを作成します。
基本的に、非常に大きなボリュームが必要で、パフォーマンスの制限にぶつからない限り、アプリケーションで 1 つの接続のみを使用しても完全に安全です。セッションは、内部で作成されたプロデューサーまたはコンシューマーのトランザクション/確認セマンティクスを制御しますが、再利用しても安全です。アプリケーション内に異なるライフサイクルを持つモジュールが存在する場合は、おそらく個別のセッションを使用します (アプリケーション サーバー内の個別のデプロイメント ユニットを考えてください)。
EMS サーバーのインストールには、さまざまなコード ( C:\tibco\ems\5.0\samples\csなど) を含むサンプル ディレクトリが含まれます。csTopicSubscriber.csのコードは、シングルスレッドのトピック コンシューマーを作成する方法を示しています。マルチスレッド トピック コンシューマーの例はありませんが、csMsgConsumerPerf.csはキューでそれを行う方法を示しています。
作成したオブジェクトは、作業が終わったら必ずクリーンアップしてください。たとえば、完了したら、トピック コンシューマ オブジェクト、セッション、および接続を閉じます。ハンドルを閉じずにリークすると、プリフェッチおよびフォールト トレラントな再接続設定と組み合わせると、予期しない動作が発生する可能性があります。
以前の回答に同意します。JMSセッションはスレッド間で共有してはなりませんが、接続は共有できます/共有する必要があります。したがって、アプリケーションごとに1つの接続で問題ありません（個々のスレッドを作成する前/後に、接続を1回だけ開始/閉じるようにしてください）。
次に、スレッドごとに1つのセッションを作成して使用します。セッションをclose（）すると、すべての受信コールバックが実際に返されるまでブロックされることに注意してください。したがって、コールバックのonMessage（）内からclose（）を呼び出さないでください。
共有が同じアプリケーション (exe、バイナリ) 内である限り、私はそう思います。同じ接続オブジェクトを共有し、コードでシングルトンとして使用しました。