5

ユーザーがWebインターフェイスから「socketinfo」テーブル（データベースに格納されている）を追加/削除できるようにするJavaEEアプリケーションを作成しています。ユーザーがWebインターフェースから「socketinfo」を有効にする場合、アプリケーションサーバーは着信パケットのソケットリスナーを作成し、データを処理する必要があります。ユーザーが「socketinfo」を無効にするか削除する場合は、ソケットリスナーを削除する必要があります。製品全体が片方の耳に含まれている必要があり、できれば準拠している必要があります。私が検討したが問題に遭遇したいくつかのアプローチは次のとおりです。

  1. ソケット用のJCAリソースアダプタを作成し、MDBをリスナーとして使用します。ここで遭遇した問題は、ユーザーがMDBを追加したときに、さまざまなソケットにMDBをプログラムでデプロイする方法がわからないことでした。

  2. 注意深く同期してデーモンスレッドを管理する@Singleton/ @Serviceejbを作成します。シングルトンejbをビジネスレイヤーに注入して、CRUD操作とソケット操作が適切なワークフローで行われるようにすることができます。ここでの問題は、EJBからスレッドを作成することは悪い習慣と見なされ、仕様に準拠していないことでした（シングルトンのライフサイクルが正しく処理され、適切な同期メカニズムが導入されている場合でも）。

  3. スレッドをドメインモデル（別のシングルトン？）に配置し、EJBにモデルを使用させます。アプリケーションサーバーには複数のクラスローダーがあり、一般にコンテナサポートが少ない傾向があるため、これはすべての中で最悪でした。さらに、これは2.苦しむすべての問題に苦しんでいます。

Java EEでこの状況を正しく処理する方法はありますか？

編集：この質問の拡張：ewernliが彼のソリューション3で示唆しているように、この問題に取り組むことにしたと仮定すると、JCA（内部スレッドを追加するカスタムインターフェイスを使用）でこれを行うことで、（うまく設計された）シングルトン？リソースアダプタの作成は大変な作業のようには見えませんが、完全に些細なことではなく、少し時間がかかる可能性があります（他の開発者にとってはさらに難しいかもしれません）。

4

2 に答える 2

1

あなたの分析は合理的であり、JCA に適合するように MDB を動的に展開することはできないと言うのは正しいことです。

さらにいくつかのデザインのアイデア:

  • SocketConnectionsソケットから読み取るために使用できる (JMS の精神で)返す JCA コネクタを作成できます。JMS の類推を続けると、MDB は を表しMessageListenerますが、公開するのはMessageConsumerです。

  • 定期的なタイマーを使用して、スレッドをシミュレートできます。while ループを持つスレッドの代わりに、タイマー自体が再スケジュールされます。これを 1 つのアプリでバックグラウンド プロセスに使用したところ、問題なく動作しました。また、EJB から直接スレッドを生成して、別のアプリでいくつかの同時計算を実行したことにも注意してください。これも問題なく動作しました。しかし、短命のスレッドと Bean 内のビジネス メソッドはすべて完了するまで待機するため、これは仕様の重大な違反ではありませんでした。

  • さらに別の設計では、JCA コネクタでスレッドなどを処理し、すべてのメッセージを MDB に配信します。MDB は、データが対応する「チャネル」 (ソケット ポートなど) に関する情報とともに、データを受信します。これは、すべてを 1 つの MDB で多重化し、データを逆多重化するようなものです。コネクタは、スレッドの作成などを制御するための追加の API を提供でき、このインターフェースを EJB に注入できます ( と同様ConnectionFactory)。コネクタは、スレッドの作成などを制御するための追加の API を提供できます。明確ではありませんが、理解していただければ幸いです。私が正しければ、JCA コネクタは、MDB が正しい順序でデータを処理できるように、少なくともソケットごとにデータを同期的に MDB に配信することができます。

開発時間が許せば、私は＃3に行きます。

編集

この選択は、確かに部分的にデザインの純度の問題です。ただし、ユーザーが生成したスレッドの 1 つの問題は、明らかに宣言型トランザクションを使用できないことです。ただし、 a を使用しUserTransactionて自分でトランザクションを区別することもできます。EntityManagerまた、そのようなスレッドでどれだけうまく使用できるかわかりません。主にデータを処理し、ミドルウェアの機能をあまり使用しない場合は、自分でスレッドを生成できます。私の別の回答を参照してください：EJBは、CPUを集中的に使用する長いプロセスをどのように並列化できますか? . 私の頭に浮かぶ他のこと (問題があるかどうかはわかりません): セキュリティ マネージャーがスレッド (?) の作成を妨げる可能性があります。サーバーが適切にシャットダウンされませんでした (?)。からスレッドを生成したことに注意してくださいServeletContextListener起動時に、それはうまくいきました。これは、仕様に違反していても頻繁に使用されるトリックです。「新しく」導入されたシングルトン Bean についても同じことが言えます。したがって、時間がない場合は、もちろん、シングルトン Bean で提案を試して、何が機能するか/機能しないかを確認できます。

于 2011-05-24T10:10:03.297 に答える
1

＃2が最良の解決策であると確信しています（また、有効です）。新しい「Singleton」ejb の仕様は見ていませんが、これらの内部でのスレッド化は許容されると思います (これらの ejb 内で独自の同期を行うことは許容されると考えてください)。これらは、以前は JMX を使用して実行できた管理タイプのサービスを簡単に (より) 展開できるように設計されています (ただし、展開は標準化されていませんでした)。 JMX mbean 内では、独自のスレッド管理を行うことは確かに許容されるので、それを Singleton ejbs に引き継ぐことになります。

ejb 3.1 仕様を簡単にざっと調べましたが、Singleton の唯一の許容範囲は同時実行制御であり、スレッド化/ソケットのものではないと思います。ちょっとばかげている。それらは本格的な JMX mbean の代替品ではないと思います。とはいえ、デプロイメントは非標準ですが、いつでも JMX mbean を使用できます。jboss を使用している場合、Service アノテーションはJMX mbean と同等であり、すべてが許容されます (スレッド、ソケットなど)。

于 2011-05-24T16:39:24.550 に答える