Sun ONE Application Server 7 Enterprise Java Beans 開発者ガイド |
Enterprise JavaBeans のトランザクション処理この章では、Sun ONE Application Server 7 の Enterprise JavaBeans (EJBs) プログラミングモデルに組み込まれたトランザクションサポートについて説明します。
注 EJB テクノロジのトランザクション処理に精通していない場合は、Java Software チュートリアルを参照してください。
http://java.sun.com/j2ee/docs.html
EJB トランザクションサポートに関する詳細情報は、『Enterprise JavaBeans Specification, v2.0』の第 17 章にあります。
Sun ONE Application Server の概要は、「Sun ONE Application Server Enterprise JavaBeans の紹介」および『Sun ONE Application Server 製品の概要』にあります。
この章には次の項目があります。
JTA トランザクションと JTS トランザクションのサポート
J2EE では、次の 2 つの仕様により分散トランザクションをサポートしています。
- Java Transaction API (JTA)
- Java Transaction Service (JTS)
JTA は、アプリケーションおよびアプリケーションサーバがトランザクションにアクセスできるようにする、実装に依存しない高レベルなプロトコル API です。
JTS は、JTA をサポートするトランザクションマネージャの実装を指定して、API の下のレベルで OMG Object Transaction Service (OTS) 1.1 仕様の Java マッピングを実装します。JTS は、Internet Inter-ORB Protocol (IIOP) を使用してトランザクションを伝達します。
トランザクションマネージャの現在の実装は、JTS と JTA をサポートしています。EJB コンテナは、Java Transaction API インタフェースを使用して JTS と対話します。
J2EE トランザクションマネージャは、Bean 管理 JBDC (Java Database Connectivity) トランザクションを除くすべての EJB トランザクションを制御し、Enterprise JavaBean がトランザクション内で複数のデータベースを更新できるようにします。
トランザクション処理について
開発者は、複数のサイトに分散された複数のデータベースのデータを更新するアプリケーションを作成できます。サイトでは、異なるベンダーの EJB サーバを使用してもかまいません。
この節では、次の各項目に関する概要を示します。
単層型トランザクション
『Enterprise JavaBeans Specification, v2.0』では、ネストとは対照的な単層型トランザクションのサポートを要求しています。単層型トランザクションでは、各トランザクションはシステムのほかのトランザクションから独立しており、依存していません。現在のトランザクションが終了するまでは、同じスレッド内で別のトランザクションを開始することはできません。
単層型トランザクションは、もっとも普及したモデルであり、ほとんどの商用データベースでサポートされています。ネストされたトランザクションでは、より精細なトランザクションの制御が可能ですが、これをサポートする商用データベースシステムはごく少数しかありません。
グローバルトランザクションとローカルトランザクション
Sun ONE Application Server でのトランザクションのサポートを理解するためには、グローバルトランザクションとローカルトランザクションの違いを理解することが重要です。
- グローバルトランザクション - リソースマネージャによって管理および調整され、複数のデータベースやプロセスにまたがることができるトランザクション。リソースマネージャは通常、XA プロトコルを使って Enterprise Information System (EIS) またはデータベースと対話する
- ローカルトランザクション - 単一の EIS またはデータベースに固有であり、1 つのプロセス内に制限されるトランザクション。ローカルトランザクションが複数のデータソースを扱うことはない
ローカルトランザクションとグローバルトランザクションはどちらも、javax.transaction.UserTransaction インタフェースによって境界が設定されるので、クライアントはこのインタフェースを使う必要があります。ローカルトランザクションはトランザクションマネージャをバイパスし、より高速です。
最初は、すべてのトランザクションがローカルトランザクションです。XA 以外のデータソースコネクションがトランザクションの範囲に指定された最初のリソースコネクションである場合、2 番目に指定された XA データソースコネクションが加わったときに、グローバルトランザクションになります。2 番目にも XA 以外のデータソースコネクションが加わろうとすると、例外がスローされます。
Sun ONE Application Server は、グローバルかローカルのどちらかのトランザクションモードで動作し、両方のモードを混在させることはできません。
注 アプリケーションでグローバルトランザクションを使うには、対応する Sun ONE Application Server のリソースマネージャを設定して使用可能にする必要があります。詳細は、Sun ONE Application Server のAdministration interfaceのオンラインヘルプ、および『管理者ガイド』を参照してください。
境界設定モデル
開発者は、EJB コード内のプログラムによるトランザクションの境界設定 (Bean 管理) か、または宣言による境界設定 (コンテナ管理) のどちらかを使用できます。Enterprise JavaBean で Bean 管理とコンテナ管理のどちらのトランザクション境界設定を使用するかに関係なく、EJB コンテナおよび Sun ONE Application Server にトランザクション管理の負荷がかかります。このコンテナとサーバは、必要な低レベルのトランザクションプロトコル (トランザクションマネージャと、dustbowls システムまたは Sun ONE Message Queue プロバイダの間の 2 階層コミットプロトコルなど)、トランザクションコンテキストの伝達、および分散型の 2 階層コミットを実装します。
次の項で、これらの境界設定モデルについて説明します。
コンテナ管理トランザクション
Enterprise JavaBean の主な利点の 1 つは、コンテナ管理トランザクション (宣言型トランザクションとも呼ばれる) に提供するサポートです。コンテナ管理トランザクションを使用する Enterprise JavaBean では、EJB コンテナがトランザクションの境界を設定します。
注 すべての種類の Enterprise JavaBean (セッション、エンティティ、メッセージ駆動型) でコンテナ管理トランザクションを使用できますが、エンティティ Bean で使用できるのはコンテナ管理トランザクションだけです。
コンテナ管理トランザクションを使用すると、EJB コードでトランザクションの境界を明示的に設定しないので、開発作業が簡素化されます。つまり、コードにはトランザクションを開始および終了するステートメントを記述しません。コンテナは、次の処理を実行します。
- トランザクションコンテキストの境界を設定し、透過的に伝達する
- トランザクションマネージャと連係して、トランザクション内のすべての関係要素に一貫した結論を参照させる
Bean 管理トランザクション
EJB の仕様では、javax.transaction.UserTransaction を使用した、Bean 管理によるトランザクションの境界設定 (プログラマによる境界設定トランザクションとも呼ばれる) をサポートしています。Bean 管理トランザクションでは、JNDI (Java Naming and Directory Interface) 検索を実行して UserTransaction オブジェクトを取得する必要があります。
注 Bean 管理トランザクションはセッション Bean またはメッセージ駆動型 Bean で使用できますが、エンティティ Bean ではコンテナ管理トランザクションを使用する必要があります。
Bean 管理トランザクションには次の 2 つのタイプがあります。
- JDBC タイプ - 接続インタフェースの commit および rollback メソッドで、JDBC トランザクションの境界を定める
- JTA タイプ - UserTransaction インタフェースの begin、commit、および rollback メソッドを呼び出して、JTA トランザクションの境界を定める
コミットオプション
EJB プロトコルは、トランザクションがコミットされたときに、インスタンスの状態を廃棄できる柔軟性をコンテナに提供するように設計されています。これにより、コンテナは、エンティティオブジェクトの状態のキャッシュや、エンティティオブジェクト ID と EJB インスタンスの関連付けを最適に管理できます。
コミット時のオプションには次の 3 つがあります。
- オプション A - コンテナは、トランザクション間で動作可能なインスタンスをキャッシュする。コンテナは、そのインスタンスが持続ストレージ内のオブジェクトの状態に排他的にアクセスできるようにする
この場合、コンテナは、次のトランザクションの開始時に、持続ストレージからインスタンスの状態の同期をとる必要はありません。
注 コミットオプション A は、Sun ONE Application Server 7 ではサポートされていません。
- オプション B - コンテナは、トランザクション間で動作可能なインスタンスをキャッシュするが、そのインスタンスが持続ストレージ内のオブジェクトの状態に排他的にアクセスできるようにはしない。これがデフォルト
この場合、コンテナは次のトランザクションの開始時に、持続ストレージから ejbLoad を呼び出してインスタンスの状態と同期をとる必要がある
- オプション C - コンテナは、トランザクション間で動作可能なインスタンスをキャッシュしないが、代わりに、トランザクションの完了後に、そのインスタンスを使用可能なインスタンスのプールに戻す
コミットオプション C における各ビジネスメソッド起動のライフサイクルは、次のようになる
ejbActivate->
ejbLoad ->
ビジネスメソッド ->
ejbStore ->
ejbPassivate同じエンティティ EJBObject に同時にアクセスしているトランザクションクライアントが 2 つ以上ある場合、最初のクライアントが動作可能なインスタンスを取得し、次の同時アクセスのクライアントがプールから新規インスタンスを取得する。
Sun ONE Application Server の配備記述子には、使用するコミットオプションを指定する commit-option 要素があります。指定したコミットオプションに基づいて、適切なハンドラがインスタンス化されます。
注 コミットオプション A を使用する場合は、開発者が確実にこのアプリケーションだけがデータベースを更新するようにする必要があります。つまり、これはコンテナの仕事ではありません。
管理と監視
管理者は、server.xml ファイル内の transaction-service 要素で、サーバインスタンス全体のトランザクションサービスに関する次の属性を制御できます。
- automatic-recovery
- timeout-in-seconds
- tx-log-directory
- heuristic-decision
- keypoint-interval
- log-level
- monitoring-enabled
これらの属性に関する詳細は、『Sun ONE Application Server 管理者用設定ファイルリファレンス』を参照してください。
さらに、管理者は、トランザクションマネージャからの統計情報を使ってトランザクションを監視できます。トランザクションマネージャは、サーバが起動してから完了したトランザクション数、ロールバックされたトランザクション数、復旧されたトランザクション数、および現在処理中のトランザクション数など、稼動状況に関する情報を提供します。
トランザクションの管理および監視については、Sun ONE Application Server のAdministration interfaceのオンラインヘルプ、および『Sun ONE Application Server 管理者ガイド』を参照してください。
コンテナ管理トランザクションの使用法
一般に、コンテナは、EJB メソッド起動の直前にトランザクションを開始し、メソッド終了の直前にそのトランザクションをコミットします。各メソッドを、1 つのトランザクションに関連付けることができます。
注 ネストされたトランザクションまたは複数のトランザクションを 1 つのメソッド内に含めることはできません。
コンテナ管理トランザクションでは、すべてのメソッドをトランザクションに関連付ける必要はありません。Enterprise JavaBean の配備時に、トランザクション属性を設定することによって、Bean のどのメソッドをトランザクションと関連付けるかを指定することができます。
コンテナ管理トランザクションを使用する Bean では、コーディングが少なくてすみますが、次の制限があります。
メソッドの実行中は、1 つのトランザクションに関連付けるか、トランザクションには一切関連付けないかのどちらかしかありません。
この制限により Bean のコーディングが困難になる場合は、Bean 管理トランザクションを選択することをお勧めします。
コミットが発生すると、トランザクションは、Bean の有効な作業が終了したことをコンテナに伝え、基礎となるデータソースと状態の同期をとるようにコンテナに指示します。コンテナはトランザクションの終了を許可し、Bean を解放します。コミットされたトランザクションに関連付けられたリザルトセットは無効になります。同じ Bean に対する連続したリクエストによって、コンテナは、基礎となるデータソースとの同期負荷 (load-to-synchronize) 状態を発行します。
注 コンテナが開始したトランザクションは暗黙的にコミットされます。
トランザクションに関連した Bean であれば、トランザクションをロールバックできます。
次の各項では、コンテナ管理トランザクションを使用する Enterprise JavaBeans の開発について説明します。
トランザクション属性の指定
トランザクション属性は、トランザクションの範囲を制御するパラメータです。
トランザクション属性は配備記述子内に保存されるので、EJB 作成時、アセンブリ (パッケージ化) 時、配備時など、J2EE アプリケーション開発中のいくつかの段階で変更が可能です。ただし、EJB 開発者は、EJB の作成時にトランザクション属性を指定する必要があります。開発者 (またはアセンブリ担当者) がコンポーネントを大規模なアプリケーションにアセンブリするときだけに、この属性を変更する必要があります。
注 J2EE アプリケーションの配備担当者がトランザクション属性を指定するという想定はしないでください。
Enterprise JavaBean 全体、または個々のメソッドのトランザクション属性を指定できます。メソッドと Bean に別々の属性を指定した場合は、メソッドの属性が優先されます。
ヒント EJB の配備記述子内にトランザクションを設定する方法がわからない場合は、コンテナ管理トランザクションを指定します。次に、Enterprise JavaBean 全体に対して Required トランザクション属性を設定します。ほとんどの場合、この方法で正しく動作します。
EJB 配備記述子ファイルの詳細は、「配備記述子の作成」を参照してください。
ここには次の項目があります。
属性の必要条件の区別
個々のメソッドの属性を指定する場合は、Bean のタイプによって必要条件が異なります。
- セッション Beans - ビジネスメソッドの属性を定義する必要がありますが、create メソッドの属性は指定できまない
- エンティティ Beans - ビジネスメソッド、create メソッド、remove メソッド、および検索メソッドのトランザクション属性が必要となる
- メッセージ駆動型 Beans - onMessage メソッドのトランザクション属性 (Required か NotSupported のどちらか) が必要となる
属性値
トランザクション属性には、次の値のいずれかを設定できます。
Required
クライアントがトランザクション内で動作中に Enterprise JavaBean のメソッドを呼び出した場合、そのメソッドはクライアントのトランザクション内で動作します。クライアントがトランザクションに関連付けられていない場合、コンテナは、新しいトランザクションを開始してからメソッドを実行します。
ヒント Required 属性は、ほとんどのトランザクションで使用できます。したがって、デフォルト値として、少なくとも開発の初期段階ではこの値を使用するとよいでしょう。トランザクション属性は宣言型であるため、あとで容易に変更できます。
RequiresNew
クライアントがトランザクション内で動作中に EJB メソッドを呼び出した場合、コンテナは、次の処理を実行します。
- クライアントのトランザクションを中断します。
- 新しいトランザクションを開始します。
- 呼び出しをメソッドに委託します。
- メソッドの完了後、クライアントのトランザクションを再開します。
クライアントがトランザクションに関連付けられていない場合、コンテナは、新しいトランザクションを開始してからメソッドを実行します。
メソッドを常に新しいトランザクション内で動作させる必要がある場合は、RequiresNew 属性を使用します。
Mandatory
クライアントがトランザクション内で動作中に EJB メソッドを呼び出した場合、そのメソッドはクライアントのトランザクション内で動作します。クライアントがトランザクションに関連付けられていない場合、コンテナは TransactionRequiredException をスローします。
EJB のメソッドでクライアントのトランザクションを使用する必要がある場合は、Mandatory 属性を使用します。
NotSupported
クライアントがトランザクション内で動作中に EJB メソッドを呼び出した場合、コンテナは、クライアントのトランザクションを中断してからメソッドを呼び出します。メソッドの完了後、コンテナはクライアントのトランザクションを再開します。
クライアントがトランザクションに関連付けられていない場合、コンテナは新しいトランザクションを開始せずに、メソッドを実行します。
Supports
クライアントがトランザクション内で動作中に EJB メソッドを呼び出した場合、そのメソッドはクライアントのトランザクション内で動作します。クライアントがトランザクションに関連付けられていない場合、コンテナは新しいトランザクションを開始せずに、メソッドを実行します。
注 メソッドのトランザクション動作は大きく異なるので、Supports 属性を使用するには注意が必要です。
Never
クライアントがトランザクション内で動作中に Enterprise JavaBean のメソッドを呼び出した場合、コンテナは RemoteException をスローします。クライアントがトランザクションに関連付けられていない場合、コンテナは新しいトランザクションを開始せずに、メソッドを実行します。
トランザクションを必要としないメソッドでは NotSupported 属性を使用してください。トランザクションはオーバーヘッドを伴うので、この属性によりパフォーマンスを高めることができます。
次の表は、各トランザクション属性の効果をまとめたものです。左の列はトランザクション属性、中央の列はクライアントトランザクションのタイプ、右の列はビジネスメソッドのトランザクションタイプを示します。トランザクションには、T1、T2、または None (なし) のタイプがあります。T1 および T2 のトランザクションはコンテナによって制御されます。
- T1 トランザクション - EJB 内でメソッドを呼び出すクライアントに関連付けらる。ほとんどの場合、クライアントは別の EJB である
- T2 トランザクション - メソッドの実行直前に、コンテナによって開始される
- None - 3 列目の None は、そのビジネスメソッドが、コンテナによって制御されるトランザクション内で実行されないことを意味する。ただし、ビジネスメソッドなどでのデータベース呼び出しは、そのデータベースのトランザクションマネージャによって制御される場合がある
コンテナ管理トランザクションのロールバック
コンテナ管理トランザクションのロールバックには、次の 2 つの方法があります。
- システム例外がスローされた場合に、コンテナが自動的にトランザクションをロールバックする
- EJBContext インタフェースの setRollbackOnly メソッドを呼び出すことによって、Bean メソッドがコンテナにトランザクションのロールバックを指示する。Bean がアプリケーション例外をスローした場合は、自動的なロールバックは行われないが、setRollbackOnly の呼び出しによってロールバックを起動できる
コンテナがトランザクションをロールバックするときは、コンテナはトランザクション内の SQL 呼び出しによって加えられたデータ変更を実行しません。ただし、エンティティ Beans の場合のみ、コンテナはインスタンス変数に加えられた変更を実行しません。その場合は、エンティティ Beans の ejbLoad メソッドを自動的に呼び出して、データベースからインスタンス変数を読み込みます。
セッション Bean では、ロールバックが発生したときに、トランザクション内で変更されたすべてのインスタンス変数を明示的にリセットする必要があります。セッション Bean のインスタンスをリセットするもっとも簡単な方法は、SessionSynchronization インタフェースを実装することです。
セッション Beans のインスタンス変数の同期化
セッション Beans にオプションで設定できる SessionSynchronization インタフェースでは、インスタンス変数とデータベース内の対応する値の同期をとることができます。コンテナは、トランザクションの主要ステージごとに SessionSynchronization メソッド (afterBegin、beforeCompletion、および afterCompletion) を呼び出します。
- afterBegin メソッド - 新しいトランザクションが開始されたことをインスタンスに知らせる。コンテナは、ビジネスメソッドを起動する直前に afterBegin を起動する。afterBegin メソッドは、データベースからインスタンスを読み込むのに適している
- beforeCompletion メソッド - コンテナは、ビジネスメソッドの完了後、トランザクションをコミットする直前に beforeCompletion メソッドを起動する。beforeCompletion メソッドは、セッション Bean が (setRollbackOnly を呼び出して) トランザクションをロールバックする最後の機会である
インスタンス変数の値によってデータベースがまだ更新されていない場合、セッション Bean は beforeCompletion メソッドでその処理を実行できる
- afterCompletion メソッド - トランザクションが完了したことを示す。このメソッドは 1 つのブール型のパラメータを持ち、その値は、トランザクションがコミットされた場合は true、ロールバックされた場合は false となる
ロールバックが発生した場合、セッション Bean は、afterCompletion メソッドでデータベースに基づいてインスタンス変数を更新できる
コンテナ管理トランザクションで使用できないメソッド
コンテナ管理トランザクションでは、コンテナが設定するトランザクション境界を侵害する可能性のあるメソッドを起動することはできません。禁止されているメソッドを次に示します。
- java.sql.Connection の commit、setAutoCommit、および rollback メソッド
- javax.ejb.EJBContext の getUserTransaction メソッド
- javax.transaction.UserTransaction のすべてのメソッド
ただし、Bean 管理トランザクションで境界を設定する場合は、これらのメソッドを使用できます。
Bean 管理トランザクションの使用法
Bean 管理トランザクションでは、セッション Bean またはメッセージ駆動型 Bean のコードでトランザクションの境界を明示的に指定します。トランザクション管理を Bean レベルに移すことによって、Bean のアクティビティがデータベースアクセスと直接結び付いていなくても、データベース呼び出しと同じトランザクション制御環境ですべての Bean アクティビティを配置できます。これにより、Bean によって制御されるアプリケーション部分はすべて、同じトランザクションの一部として動作します。
障害発生時は、その Bean が管理していたすべてのものがコミットされるか、ロールバックされます。
次の各項では、Bean 管理トランザクションを使用する Enterprise JavaBeans の開発について説明します。
トランザクションタイプの選択
セッション Beans またはメッセージ駆動型 Beans の Bean 管理トランザクションをコーディングするときは、JDBC または JTA のどちらのトランザクションを使用するかを決める必要があります。
注 Bean 管理トランザクションを使用するセッション Bean では、JDBC と JTA のトランザクションを組み合わせて使用できます。ただし、コードのデバッグおよび保守が難しくなるのでお勧めできません。
次に、両方のトランザクションタイプについて説明します。
JDBC トランザクション
JDBC トランザクションは、データベースのトランザクションマネージャによって制御されます。セッション Beans 内に従来のコードを挿入するときは、JDBC トランザクションの使用をお勧めします。
JDBC トランザクションをコーディングする場合は、java.sql.Connection インタフェースの commit および rollback メソッドを起動します。トランザクションの開始は暗黙的に判別されます。トランザクションは、最新の commit、rollback、または connect ステートメントに続く最初の SQL ステートメントで始まります。通常はこのルールが当てはまりますが、データベースベンダーによっては異なる場合もあります。
JDBC の詳細は、『Sun ONE Application Server Developerユs Guide to J2EE Features and Services』を参照してください。
JTA トランザクション
JTA では、トランザクションマネージャの実装に依存しない方法でトランザクションの境界を設定できます。J2EE SDK は、JTS によるトランザクションマネージャを実装しています。しかし、コードでは JTS メソッドを直接呼び出しません。その代わりに、低レベルの JTS ルーチンを呼び出す JTA メソッドを起動します。
JTA トランザクションは、J2EE トランザクションマネージャによって制御されます。異なるベンダーによる複数のデータベースにわたって更新できるため、JTA トランザクションを使用したいと考える場合があります。ただし、特定のデータベースのトランザクションマネージャは異種データベースで動作しない場合があります。
J2EE トランザクションマネージャには、ネストされたトランザクションをサポートしていないという制約があります。つまり、前のトランザクションが終了するまでは、インスタンスのトランザクションを開始できません。
JTA の詳細は、『Sun ONE Application Server Developerユs Guide to J2EE Features and Services』を参照してください。
コミットなしの復帰
ビジネスメソッドでトランザクションを開始した、Bean 管理トランザクションのステートレスセッション Bean は、復帰前にトランザクションをコミットまたはロールバックする必要があります。ただし、ステートフルセッション Beans には、この制約はありません。ステートフルセッション Beans で JTA トランザクションを使う場合、Bean インスタンスとトランザクションの関連付けが複数のクライアント呼び出しで保持されます。
Bean 管理トランザクションで使用できないメソッド
Bean 管理トランザクションでは、EJBContext インタフェースの getRollbackOnly および setRollbackOnly メソッドを起動しないでください。これらのメソッドは、コンテナ管理トランザクションだけで使用されます。
注 Bean 管理トランザクションでは、UserTransaction インタフェースの getStatus および rollback メソッドを起動します。
トランザクションタイムアウトの設定
コンテナ管理トランザクションでは、server.xml ファイル内の timeout-in-seconds プロパティの値を設定することによって、トランザクションタイムアウト間隔を制御します。たとえば、タイムアウト値を 5 秒に設定するには、次のように指定します。
timeout-in-seconds=5
この設定では、トランザクションが 5 秒以内に完了しなかった場合、EJB コンテナはそのトランザクションをロールバックします。
注 コンテナ管理トランザクションを使用する Enterprise JavaBeans だけが timeout-in-seconds プロパティの適用対象となります。Bean 管理の JTA トランザクションを使用する Enterprise JavaBeans では、UserTransaction インタフェースの setTransactionTimeout メソッドを起動します。
遮断レベルの処理
トランザクションは、トランザクションの内側にあるステートメントを完全に完了 (またはロールバック) するだけでなく、ステートメントによって変更されたデータを遮断します。遮断レベルは、更新されるデータがほかのトランザクションに見える度合いを示します。
トランザクションで、コミットされていないデータをほかのプログラムが読み取ることができるようにすると、ほかのプログラムはそのトランザクションが終了するまで待つ必要がなくなるので、性能を高めることができます。しかし、トランザクションがその後ロールバックされると、他のプログラムは間違ったデータを読み取ってしまうという問題が起こる可能性もあります。
Bean 管理による持続性を使用するエンティティ Beans、およびすべてのセッション Beans では、基礎となるデータベースによって提供される API を使って、プログラムで遮断レベルを設定できます。たとえば、データベースでは、setTransactionIsolation メソッドを起動することによって、コミットされていない読み取りを許可することができます。
コンテナ管理による持続性を使用するエンティティ Beans では、sun-cmp-mapping.xml ファイルの consistency 要素を使って遮断レベルを設定できます。
警告
トランザクションの途中で遮断レベルを変更しないでください。通常、そのような変更は、データベースソフトウェアで暗黙的なコミットが発生する原因となります。データベースベンダーが提供する遮断レベルはさまざまなので、データベースのマニュアルで詳細を確認する必要があります。J2EE プラットフォームでの遮断レベルは標準化されていません。