問題タブ [bean-managed-transactions]

トランザクション セマンティクスとステート フルネスは、EJB3 での実装の詳細と見なされます。実装は、Bean 管理のトランザクションを使用するかコンテナー管理のトランザクションを使用するかを決定できます。コンテナ管理トランザクションのタイプを決定できます。ステートフルかステートレスかを判断できます。

ただし、論理的には、これらは重要なインターフェイスの詳細です。例: (a) Bean 管理のトランザクションを使用する Bean は、コンテナー管理のトランザクションを使用する Bean を呼び出すことはできません。(b) ステートレス Bean はステートフル Bean を呼び出すことができません。

EJB3 インターフェースが提示されたとき、必要なトランザクション セマンティクスの種類がわかりません。同様に、ステートフルかステートレスかはわかりません。追加の実装の詳細が必要です。例: ドキュメント。

実行時に、さまざまな Bean と呼び出しチェーンを動的にインスタンス化できます。したがって、無効な状態が発生する可能性があります。現在 - コンテナはこれらの状況をトラップできます。しかし、なぜランタイムまで待つのですか?

トランザクションのセマンティクスと完全な状態の要件がインターフェイスの一部ではないのはなぜですか?

Seamは、Seamで管理された永続性を実現するために、ステートフルセッションBeanで拡張永続コンテキストを使用することをお勧めします。

上記のアドバイスが、Seamで管理されるトランザクションの方法に影響を与えるかどうかはわかりません。これは、アーキテクチャが異なるためです。ステートレスEJBには次の永続コンテキストがあります。

上記のCrudServiceBeanを呼び出すDAOは、@ TransactionAttribute（TransactionAttributeType.REQUIRED）を使用するステートレスEJB（一部はSeamコンポーネントでもあります）です。したがって、トランザクションはSeamではなくコンテナ（WebLogic）によって処理されます。

ただし、次のシナリオを満たす必要があります。フロントエンドのSeamコンポーネント（非EJB）で複数のDAO（EJB）メソッドを呼び出し、それらすべてを1つのトランザクションでラップする必要があります。私が正しく理解していれば、Seamで管理されたトランザクションが必要です。

Seam管理の永続コンテキストがなくても、説明したシナリオのようにSeam管理のトランザクションを実行できますか？それとも、2つは無関係ですか？

Bean 管理のトランザクションを使用するステートレス Bean と、次のようなメソッドがあります。

では、どのようにしてBeanにUserTransaction伝播するのでしょうか?OtherStatelessBeanLocal

コンテナ管理の永続性を使用する JSF/EJB/JPA アプリケーションがあります。コストのある HTTP を介して外部サービスへの呼び出しが行われるケースが 1 つあります。このコストは、要求元のユーザーに割り当てられます。現在の実装では、HTTP 要求を作成するプロセスは、バックグラウンドで定期的に実行される EJB タイマー メソッドによって実行されます。

タイマー メソッドは、1 回の呼び出しで多数の要求を処理する必要がある場合がありますが、各要求は個別に、ユーザーへのコストの割り当てに関して個別に処理する必要があります。ユーザー A が書籍を購入するのに十分なクレジットを持っていない場合でも、ユーザー B による書籍の購入が妨げられて、ロールバックのために残高が引き落とされてはなりません。

各リクエストを独立して処理するためにトランザクション境界を制御するために、タイマー メソッドが存在するクラスに Bean 管理のトランザクションを使用しています。これは、私が今持っているものの Java 疑似コード バージョンです。

したがって、トランザクションを開始し、成功を想定してユーザーからコストを引き落とし、http サービスを呼び出して、成功した場合はコミットするか、そうでない場合はロールバックするという考え方です。

私は、特に pessimistic_write トランザクション内で長い http 呼び出し (実際には jax-rs を使用して行われる) があるため、この設計では正しい球場の近くにいないのではないかと不安に思っています。最初に、トランザクション内でユーザーのデビット (begin/debit/commit) を行い、http 呼び出しを行い、エラーが発生した場合にユーザーにクレジットを与えることができるかどうか疑問に思いましたが、トランザクションの整合性はありません。

これは私にとって新しい領域です。誰かが私を正しい方向に向けることができますか?私がやろうとしていることを行うための確立された方法はありますか?

どうもありがとう。

ps Seam 3でglassfish 3.1スタックを使用しています

セッションBeanでCMTを使用する場合、トランザクションをどこでコミットしますか？

REQUIRES_NEW属性を使用すると、コンテナは新しいトランザクションを作成し、呼び出し元のトランザクションは一時停止されます。REQUIRES_NEWをよりよく理解するだけで、トランザクションを新しい接続に関連付けることで上記の動作を実現できますか。現在のトランザクションを完了すると、前の接続を想定しますか？新しいトランザクションでコミットが発生したのはいつですか？

誰かが私に、JDBCを使用したセッションBeanの簡単な簡単なCMTとBMTを教えてもらえますか。基本的に、CMTとBMTで接続、コミット、ロールバックを取得する方法を調べます

CMTでは、トランザクションマネージャーは現在のスレッドに関連付けられているトランザクションを完了します。ここでの私の質問は、トランザクションをどのようにコミットするかです。接続を使用してトランザクションをコミットすることは知っていますが、ここでは、new演算子を使用してメソッド内に接続を作成する例のように、現在のスレッドに関連付けられている接続をどのように知ることができますか。

まず第一に、私の質問は、JavaでのトランザクションAPIの必要性は何ですか？実例を教えてください。

コンテナ管理トランザクションとBean管理トランザクションの意味は何ですか？

そして、宣言型トランザクションとプログラム型トランザクションの違いは？

私を助けてください

前もって感謝します

OracleデータベースでGlassfish3.1.1を実行していますが、トランザクションがロールバックされないという問題が発生しましたが、これまでのところ1つの特定の環境でのみ発生しています。同じアプリケーションが他のマシンで期待どおりに機能します。ただし、同じマシン上の2つの別々のGlassfishドメインが影響を受けます。

影響を受ける環境内では、RuntimeExceptionをスローするEJB内のコンテナー管理トランザクション（CMT）と、を使用したBean管理トランザクション（BMT）の両方で同様の結果が得られUserTransaction#rollback()ます。

どちらの場合も、根本的な問題は、進行中のJTAトランザクションがある場合でも、JDBC接続がautoCommit=trueで設定されていることであるように見えます。

私のEJB/CMTテストは次のようになります。

私のBMT/UserTransactionテストは次のようになります。

いずれかのメソッドを呼び出すとINSERT INTO FOO、トランザクションがロールバックされた場合でも、がコミットされます。

何が欠けていますか？接続プールがない/データソースが正しく設定されていない可能性がありますか？

データソースクラス名としてOracleConnectionPoolDataSourceを使用しています。データベース接続がJTAトランザクションに確実に参加するために必要なことはありますか？

UPDATE 1もともとこれは問題だと思ってOracleConnectionPoolDataSourceいましたが、相関関係がないことがわかりました。同じ正確なプール構成が一方の環境で機能しますが、もう一方の環境では機能しません。

UPDATE2これは特にEJB/CMTの問題ではなく、一般的なJTAの問題であることを明確にしました。

UPDATE 3は、JDBC自動コミットに関する情報を追加しました。persistence.xmlが正しいことを確認しました。

EJB 3.0 仕様によると、インスタンスがトランザクション内にある間、インスタンスはリソース マネージャ固有のトランザクション境界 API を使用しようとしてはなりません (たとえば、java.sql.Connection インターフェイスまたはjavax.jms.Session インターフェイス) 仕様の 13.3.3。1 つの例を試してみました - BEAN 管理のトランザクションに java.sql.Connection.commit() を含めました - NetBeans でステートレス Bean を EE5 として作成し、Glassfish 3.1 にデプロイしましたが、コンテナは文句を言いませんでしたか? Bean メソッドは、Glassfish ログにエラーなしでデータベースを更新します。これは予想される動作ですか？

また、仕様に記載されているコンテナー トランザクション管理トランザクションを持つ Bean に対して java.sql.Connection.commit() を使用する場合、そのような制限はありません。ありがとうブラニスラフ