私は、メッセージ駆動型Bean（MDB）の複数のインスタンスがリッスンするメッセージキューに複数の作業単位を配置することで並行性が達成されるデータ処理アプリケーションで作業します。このように並行性を達成していなければ、メッセージングインフラストラクチャとMDBを使用する特別な理由はありません。マルチスレッドの代わりにメッセージング（JMSなど）はいつですか？
これは私に、なぜ同じものが複数のスレッドを使用して達成できなかったのかと考えてくれました。
私の質問は、非同期メッセージング（JMSなど）を同時スレッド化の手段としてmutithreadingの代替手段として使用することができますか。 1つのアプローチを別のアプローチよりも使用することのメリットとデメリットは何ですか？
マルチスレッドの代わりに使用することはできませんが、マルチスレッドを実装する方法です。ここには3つの基本的なソリューションがあります。
受信データはここではキッカーです。何らかの形のマルチスレッディング/マルチプロセッシングがなければ、データを受信することはできません。そうしないと、一度に1つのリクエストしか処理できません。マルチスレッド化せずにデータを送信する方がはるかに実行可能ですが、実際にはこれらのメッセージを処理する責任を外部システムに押し付けるだけです。したがって、マルチスレッド化の代替手段ではありません。
メッセージ駆動型Beanの場合は、コンテナがスレッドを作成して管理しているため、マルチスレッドの代わりではなく、他の誰かの実装を使用しています。
メッセージングで追加のネットワークレイヤーを追加するため、パフォーマンスに優れたマルチスレッド化はどのメッセージングよりも高速にする必要があります。
アプリケーションワイズメッセージングは、共通オブジェクトがないため、ロックおよびデータ共有の問題を回避するのに役立ちます。
スケーラビリティの観点から、アプリケーションを変更するのではなくメッセージサービスを構成することで、複数のサーバーにただ多くのノードを構成できるため、メッセージングの方がはるかに優れています。
メッセージングは、データ競合のリスクを低減するため、マルチスレッドアプリケーションのエラー数を大幅に削減することができます。また、残りのアプリケーションを変更することなく、新しいスレッドの追加が簡単になります。
ここではJMSがやや悪用されると思いますがjava.util.concurrentのスレッドセーフなキューとライブラリはjetlangのように優れたパフォーマンスを提供します。
EJBコンテナでは、独自のスレッドをEJBコンテナに作成することが許可されていないため、実際には代替手段はありません。 JMSは、キュープロセッサを介して実行する代わりに、すべての作業を実行しています。また、Java Connectorを作成することもできます。Java Connectorは、コンテナと密接な関係にあり（したがって、スレッドを持つこともできますが）、はるかに多くの作業が必要です。
JMSキューを使用するオーバーヘッドがパフォーマンスに影響しない場合は、最も簡単な解決策です。 取引と耐久性：私は言及されているとは思わない二つの追加ボーナスがあり
技術的にはJ2EEコンテナにスレッドを作成すべきではありませんが、Webコンテナ内でこれを行うのは一般的です。 J2EE仕様は、ルールよりも多くのガイドラインと見なすべきです。結局のところ、ファイルシステムへの直接アクセスも許可されていませんが、設定ファイルなどを使ってこれをいつもやっています。特にSpringを使用する場合。 – cletus
です。
必須ではなく、しばしばデフォルトの設定ではありませんが、JMSプロバイダはメッセージを永続化し、コードの変更がほとんどまたはまったくないXAトランザクションに参加するように設定できます。
はい、それはシステム/モジュールをデカップリングするのにとても良い方法です。これは、システムのシステムを、サーバークラッシュなどの技術的問題に対してより弾力性のあるものにします。 –
ほとんどの場合、非同期メッセージングはマルチスレッド化 – skaffman