クライアントが呼び出すことができるいくつかの操作を公開し、トランザクションを管理するものになるJavaスタンドアロンアプリケーション(アプリケーションサーバーが接続されていない)を持つことは可能ですか?
このアプリケーションがJNDIリソースを公開し、そこから Java:comp/UserTransaction を取得し、そこからBeanも取得し、メソッドA、B、Cを呼び出して、トランザクションを調整することを考えていました。クライアントから?
私が書いているアプリケーションは複雑ではないので、その周りに大きなアプリケーションサーバーが必要なので、トランザクションの観点からクライアントが対話できるスタンドアロンのJTSを内部に配置することを考えています。
私は分散トランザクションの経験があまりなく、この問題に取り組む方法を本当に知りません。それも可能ですか?私は、単なる人間(プログラマー)が扱える範囲を超えたものに自分を入れていますか?
どうすればこれにアプローチできますか?
Jboss および他のアプリケーションサーバーベンダーは、スタンドアロンで使用できるスタンドアロンのトランザクションマネージャーを提供しています。
JBoss Transaction Service(JBossTS)は、Javaベースのアプリケーション(JEEおよびEJBフレームワーク用に作成されたものを含む)の完全で正確なビジネストランザクションを保証することにより、データ破損からビジネスを保護します。これにより、関連するリスクとコストが排除されます。失敗した後、時間のかかる手動調整で...
単純なJNDIサービングは簡単で、分散トランザクション管理は難しい
オラクルが提供するかなりの JNDIに関する包括的なチュートリアル があります。日付が付けられているように見えますが(JDK 1.1.2誰か?)、JNDI仕様はその間にあまり変更されておらず、依然として関連しています。例を注意深く読むと、JNDI要求に応答して内部オブジェクトを提供できるスタンドアロンアプリケーションを構築するのに十分な情報が得られます。
分散トランザクションが必要ですか?
2番目の質問は、分散トランザクションの処理に関するものです。アプリケーション間のコラボレーションのレベルに基づいて分散トランザクションを解釈する方法はいくつかあります。
単純なケースでは、次のようなワークフローがあります。
明らかに、この種のワークフローを実装するためにJNDIは必要ありません。ただし、アプリケーション(アプリケーションC)がアプリケーションBにデータベース接続プールを提供する役割を担う場合を除きます(ヒント:use C3P forそれ)。
複雑なケースでは、次のようなワークフローがあります。
複雑なケースのようなワークフローを探しているなら、それを管理するためのアプリケーションコンテナを検討する必要があると思います。そうでない場合は、JNDIも必要ない場合があります。