|
| Sun ONE Application Server 7, Update 1 管理者ガイド |
トランザクションはビジネスにとって不可欠な部分です。一般的なビジネストランザクションには、2 つ以上の関連する組織の間での資産譲渡などがあります。通常、厳密な記録が 1 つ以上のデータベースに保存されます。これらの情報はビジネスオペレーションにとって重要な意味を持つため、正確さ、即時性と信頼性が必要となります。トランザクション処理の開発は、初心者のプログラマには困難です。J2EE プラットフォームは、ある程度の抽象化によって、信頼できるトランザクション処理アプリケーションの開発を容易にしています。この章では、J2EE トランザクションと、Sun ONE Application Server のトランザクションサポートについて説明します。
この章では、一般的な Java トランザクションと、Sun ONE Application Server に組み込まれている固有のトランザクションサポートについて説明します。
この章では次のトピックについて説明します。
- トランザクションとは
- J2EE のトランザクション
- トランザクションリソースマネージャ
- ローカルトランザクションと分散トランザクション
- コンテナ管理トランザクション
- Bean 管理トランザクション
- トランザクションサービスの管理
トランザクションとは
ビジネストランザクションをエミュレートするには、プログラムによって複数のステップを実行する必要があります。たとえば、金融処理のプログラムでは、次の擬似コードで示されるような複数のステップを実行して、当座預金から普通預金に資金を移動することがあります。
begin transaction
debit checking account
credit savings account
update history log
commit transaction
上記の擬似コードでは、begin ステートメントと commit ステートメントによって、トランザクションの境界をマーク付けしています。このトランザクションを完了するには、3 つのステップがすべて成功することが必要です。3 つのステップのすべてが成功しなかった場合は、データの整合性が失われる可能性があります。
このような保証を原子性 ( atomicity ) と呼びます。トランザクションの終了方法には、コミット (commit) またはロールバック (rollback) による 2 種類があります。トランザクションのコミット時には、トランザクション境界内のステートメントによる変更は永久に保存されます。変更内容は「永続的」です。つまり、その後にシステム障害が発生した場合でも存続します。トランザクション内のいずれかのステートメントが失敗した場合、トランザクションはロールバックします。このとき、その時点までにトランザクションで実行されたすべてのステートメントによる効果を元に戻します。たとえば、上記の擬似コードで、ディスクドライブが credit のステップでクラッシュした場合、トランザクションはロールバックし、debit ステートメントで変更されたデータを元に戻します。
トランザクションが失敗した場合でも、トランザクションアカウントが保たれているため、データの整合性は保たれます このようなトランザクションの動作を、トランザクションの「整合性」と呼びます。
トランザクションサービスは、「遮断」も提供します。つまり、トランザクションがコミットまたはロールバックされるまで、他のアプリケーションやスレッドから、トランザクションのフェーズを調べることができません。トランザクションがコミットされた後は、アプリケーションやスレッドはコミットされたトランザクションを安全に調べることができます。
J2EE のトランザクション
J2EE のトランザクション処理には、トランザクションマネージャ、アプリケーションサーバー、リソースマネージャ、リソースアダプタ、およびユーザーアプリケーションの 5 つの関係要素が含まれます。これらの各エンティティは、次に説明する API や機能を実装することにより、信頼性のあるトランザクション処理を実現しています。
- トランザクションマネージャは、トランザクション境界、トランザクションリソース管理、同期化、およびトランザクションコンテキスト伝達のサポートに必要なサービスと管理機能を提供する
- アプリケーションサーバーは、トランザクション状態管理を含むアプリケーションランタイム環境のサポートに必要なインフラストラクチャを提供する
- リソースマネージャは、リソースアダプタを通じて、リソースへのアプリケーションアクセスを提供する。トランザクションマネージャがトランザクションの関連付け、完了およびリカバリ作業を行う際に使用するトランザクションリソースインタフェースを実装することによって、リソースマネージャは分散トランザクション処理を実行する。このようなリソースマネージャの例としては、リレーショナルデータベースサーバーがある
- リソースアダプタはシステムレベルのソフトウェアライブラリで、リソースマネージャへ接続するためにアプリケーションサーバーまたはクライアントが使用する。通常、リソースアダプタはリソースマネージャに固有となる。リソースアダプタはライブラリとして使用可能で、クライアントのアドレス空間内で使用される。このようなリソースアダプタの例としては、JDBC ドライバがある
- J2EE アプリケーションサーバー環境で動作するように開発された従来のユーザーアプリケーションは、JNDI を使って、トランザクションデータソースおよびトランザクションマネージャ (オプション) を検索する。宣言による EJB のトランザクション属性、または明示的なプログラムによるトランザクション境界を使用する
リソースマネージャとリソースアダプタには密接な関係があるため、これらの用語は同じ意味で使われることがあります。
トランザクションリソースマネージャ
J2EE トランザクションでは、次のトランザクションリソースマネージャがサポートされています。
データベース
J2EE アプリケーションでもっとも多く使われるトランザクションリソースマネージャはデータベースです。JDBC は、J2EE コンポーネントがデータベースへのアクセスで使う API です。データベースリソースは、JDBC リソースとして設定されます。JDBC リソースは、リソースマネージャである JDBC ドライバによって管理されます。JDBC ドライバは、ローカルトランザクションまたはグローバルトランザクションのサポートを提供します。場合によっては、これら両方のサポートを提供します。
Sun ONE Application Server は、さまざまな J2EE コンポーネントから JDBC およびトランザクションの使用をサポートしています。JDBC リソースの登録方法と設定方法の詳細については、「JDBC リソースについて」を参照してください。アプリケーションサーバーは、トランザクションの継続 (トランザクションの起動と、複数のアプリケーションコンポーネントからのデータベースアクセス) に対して責任を持ちます。たとえば、サーブレットはトランザクションを起動し、データベースにアクセスし、同じトランザクションの一部として同じデータベースにアクセスするエンタープライズ Bean を呼び出し、最後にトランザクションをコミットします。
JMS プロバイダ
JMS は Java Message Service の略語です。JMS プロバイダは、メッセージブローカサービスに対する J2EE 用語です。JMS API は、トランザクションによるアプリケーション間の信頼性できるメッセージ交換を提供します。J2EE では、トランザクションの JMS データソースをサポートする機能が必要とされています。JMS リソースと JDBC リソースは、同じトランザクションに使用できます。
Sun ONE Application Server は、Sun ONE メッセージキュー、完全機能の JMS プロバイダ、および対応するトランザクションリソースマネージャと統合されています。そのため、Sun ONE Application Server では、サーブレット、JSP ページ、およびエンタープライズ Beans からのトランザクションによる JMS アクセスが可能です。また、Sun ONE Application Server では、サードパーティの JMS プロバイダを使うこともできます。詳細については、「JMS サービスの使用」を参照してください。
J2EE コネクタ
Sun ONE Application Server は、XATransaction モードをトランザクションリソースマネージャとして使うリソースアダプタをサポートしています。プラットフォームが、サーブレット、JSP ページ、およびエンタープライズ Beans からのトランザクションによるリソースアダプタへのアクセスを有効にしていることが必要です。単一のトランザクション内で、複数のアプリケーションコンポーネントからリソースアダプタへアクセスすることができます。たとえば、サーブレットはトランザクションを起動し、リソースアダプタにアクセスし、同じトランザクションの一部としてリソースアダプタにアクセスするエンタープライズ Bean を呼び出し、最後にトランザクションをコミットします。
ローカルトランザクションと分散トランザクション
単一のリソースだけを対象とする場合は、ローカルトランザクションを使って完了できます。ローカルトランザクションでは、関係するすべてのアプリケーションコンポーネントが 1 つのプロセスで実行することも必要です。複数のリソースを対象とするトランザクション、つまり複数の関連プロセスを含むトランザクションは、分散トランザクションまたはグローバルトランザクションとなります。ローカルトランザクションの最適化では、最適化に固有のリソースマネージャが使われ、J2EE アプリケーションに透過であることが重要となります。
トランザクションのタイプは、主に関連するリソースマネージャに実装されるインタフェースにより決まります。たとえば、javax.sql.DataSource インタフェースを実装する JDBC データソースは、ローカルトランザクションに属します。javax.sql.XADataSource を実装するデータソースは、グローバルトランザクションに関係します。JDBC リソースには両方のインタフェースを実装するものもあります。そのような JDBC リソースを Sun ONE Application Server で実装するときには、Sun ONE Application Server に追加の設定を行い、このリソースで優先する機能を指定する必要があります。
ローカルトランザクションは、グローバルトランザクションに比べて単純で効率的です。ただし、変換対象のデータが複数のデータソースに分散している場合、ローカルトランザクションは不適切です。トランザクションで使用されるデータソースの数を予測することが不可能な場合もあります。そのため、実際にはグローバルトランザクションがよく使用されます。グローバルトランザクションでは、パフォーマンスを向上させるための最適化を行うことができます。
J2EE は、トランザクション内の複数のエンタープライズ Beans にアクセスするサーブレットや JSP の任意の組み合わせを構成するようなトランザクションアプリケーションをサポートしています。各コンポーネントは、1 つ以上の接続を確立して、1 つ以上のトランザクションリソースマネージャにアクセスします。次の図では、呼び出しツリーの開始点は、複数のエンタープライズ Beans にアクセスするサーブレットまたは JSP です。これらのエンタープライズ Beans は、さらに他のエンタープライズ Beans にアクセスします。コンポーネントは、接続を介してリソースマネージャにアクセスします。
トランザクションでリソースにアクセスする J2EE コンポーネント
たとえば、アプリケーションでは、単一のトランザクションで上の図のすべてのコンポーネントがリソースにアクセスすることが必要な場合があります。アプリケーションサーバーのプロバイダは、そのようなシナリオをサポートするトランザクションの機能を提供する必要があります。
J2EE のトランザクション管理は、フラットなトランザクションをサポートしています。フラットなトランザクションでは、子の (入れ子になっている) トランザクションを持つことはできません。
分散トランザクションでは、トランザクションの回復が大切です。重要なポイントでリソースにアクセスできなくなった場合、またはその他の回復不可能なエラーが発生した場合、分散トランザクションの状態が不明になることがあります。未完了のトランザクションの自動または手動による回復は、Sun ONE Application Server の重要な機能です。管理インタフェースを使うと、自動トランザクション回復を有効にできます。トランザクション回復の制御方法については、「トランザクションサービスの管理」を参照してください。
接続 (ここではリソースと同義語) は、共有可能または共有不可能のいずれかとしてマーク付けできます。接続を非共有として使用する J2EE アプリケーションコンポーネントは、有効な配備情報を提供して、接続がコンテナに共有されないようにする必要があります。これが必要になる例としては、セキュリティ属性、遮断レベル、文字設定、およびローカライズ設定の変更時などがあります。
コンテナは、共有不可能とマーク付けされた接続を共有できません。接続が共有不可能とマーク付けされていない場合は、接続は実際に共有されているかどうかに関わらず、アプリケーションに透過であることが必要です。
J2EE アプリケーションコンポーネントは、オプションの配備記述子要素 res-sharing-scope を使って、リソースマネージャへの接続が共有可能であるかどうかを示す場合があります。配備情報が提供されていない場合、コンテナは接続が共有可能であると仮定します。J2EE アプリケーションコンポーネントは、接続オブジェクトをキャッシュし、複数のトランザクションで再利用することがあります。接続の共有を提供するコンテナは、ディスパッチ時にキャッシュされた接続オブジェクトを透過的に切り替えて、正しいトランザクション範囲で適切な共有接続を指す必要があります。
エンタープライズ Bean アプリケーションの設計時には、開発者は境界をどのように指定するかを決める必要があります。
コンテナ管理トランザクション
コンテナ管理トランザクションを使用するエンタープライズ Bean では、EJB コンテナがトランザクションの境界を設定します。セッション、エンティティ、またはメッセージ駆動型の任意のタイプのエンタープライズ Bean を使用するコンテナ管理トランザクションを使うことができます。コンテナ管理トランザクションを使用すると、エンタープライズ Bean コードでトランザクションの境界を明示的に設定しないので、開発作業が簡素化されます。コードにはトランザクションを開始および終了するステートメントを記述しません。
通常、エンタープライズ Bean メソッドが起動する直前に、コンテナはトランザクションを開始します。メソッドが終了する直前に、コンテナはトランザクションをコミットします。各メソッドを、1 つのトランザクションに関連付けることができます。ネストされたトランザクションまたは複数のトランザクションを 1 つのメソッド内に含めることはできません。
コンテナ管理トランザクションでは、すべてのメソッドをトランザクションに関連付ける必要はありません。Bean の配備時に、トランザクション属性を設定することによって、Bean のどのメソッドをトランザクションと関連付けるかを指定することができます。
この節には次の項目があります。
トランザクション属性
トランザクション属性は、トランザクションの範囲を制御します。次の図で、範囲の制御が重要である理由を示します。method-A はトランザクションを開始し、Bean-2 の method-B を呼び出します。このとき、method-B が、method-A の起動したトランザクションの範囲内で動作するか、新しいトランザクションで動作するかは、method-B のトランザクション属性によって決まります。
トランザクション属性
トランザクション属性には、次の値のいずれかを設定できます。
Required
クライアントがトランザクション内で動作中にエンタープライズ Bean のメソッドを呼び出した場合、そのメソッドはクライアントのトランザクション内で動作します。クライアントがトランザクションに関連付けられていない場合、コンテナは、新しいトランザクションを開始してからメソッドを実行します。
Required 属性は、ほとんどのトランザクションで使用できます。したがって、デフォルト値として、少なくとも開発の初期段階ではこの値を使用するとよいでしょう。トランザクション属性は宣言型であるため、あとで容易に変更できます。
RequiresNew
クライアントがトランザクション内で動作中にエンタープライズ Bean のメソッドを呼び出した場合、コンテナは、次の処理を実行します。
- クライアントのトランザクションを中断する
- 新しいトランザクションを開始する
- 呼び出しをメソッドに委任する
- メソッドの完了後、クライアントのトランザクションを再開する
クライアントがトランザクションに関連付けられていない場合、コンテナは、新しいトランザクションを開始してからメソッドを実行します。
メソッドを常に新しいトランザクション内で動作させる必要がある場合は、RequiresNew 属性を使用します。
Mandatory
クライアントがトランザクション内で動作中にエンタープライズ Bean のメソッドを呼び出した場合、そのメソッドはクライアントのトランザクション内で動作します。クライアントがトランザクションに関連付けられていない場合、コンテナは TransactionRequiredException をスローします。
エンタープライズ Bean のメソッドでクライアントのトランザクションを使用する必要がある場合は、Mandatory 属性を使用します。
NotSupported
クライアントがトランザクション内で動作中にエンタープライズ Bean のメソッドを呼び出した場合、コンテナは、クライアントのトランザクションを中断してからメソッドを呼び出します。メソッドの完了後、コンテナはクライアントのトランザクションを再開します。
クライアントがトランザクションに関連付けられていない場合、コンテナは新しいトランザクションを開始せずに、メソッドを実行します。
トランザクションを必要としないメソッドでは NotSupported 属性を使用してください。トランザクションはオーバーヘッドを伴うので、この属性によりパフォーマンスを高めることができます。
Supports
クライアントがトランザクション内で動作中にエンタープライズ Bean のメソッドを呼び出した場合、そのメソッドはクライアントのトランザクション内で動作します。クライアントがトランザクションに関連付けられていない場合、コンテナは新しいトランザクションを開始せずに、メソッドを実行します。
メソッドのトランザクション動作は大きく異なるので、Supports 属性を使用するには注意が必要です。
Never
クライアントがトランザクション内で動作中にエンタープライズ Bean のメソッドを呼び出した場合、コンテナは RemoteException をスローします。クライアントがトランザクションに関連付けられていない場合、コンテナは新しいトランザクションを開始せずに、メソッドを実行します。
属性のまとめ
次の表は、各トランザクション属性の効果をまとめたものです。T1 および T2 のトランザクションはコンテナによって制御されます。T1 トランザクションは、エンタープライズ Bean 内でメソッドを呼び出すクライアントに関連付けられます。ほとんどの場合、クライアントは別のエンタープライズ Bean になります。T2 トランザクションは、メソッドの実行直前に、コンテナによって開始されます。
最後の列 (ビジネスメソッドのトランザクション) の「なし」は、そのビジネスメソッドが、コンテナによって制御されるトランザクション内で実行されないことを意味しています。ただし、ビジネスメソッドなどでのデータベース呼び出しは、DBMS のトランザクションマネージャによって制御される場合があります。
トランザクション属性
トランザクション属性
クライアントのトランザクション
ビジネスメソッドのトランザクション
Required
なし
T2
T1
T1
RequiresNew
なし
T2
T1
T2
Mandatory
なし
エラー
T1
T1
NotSupported
なし
なし
T1
なし
Supports
なし
T1
なし
T1
トランザクション属性の設定
トランザクション属性は配備記述子内に保存されるため、エンタープライズ Bean 作成時、アプリケーションのアセンブリ時、配備時など、J2EE アプリケーション開発中のいくつかの段階で変更が可能です。ただし、開発者は、Bean の作成時にトランザクション属性を指定する必要があります。アプリケーション開発者がコンポーネントを大規模なアプリケーションにアセンブリするときだけ、この属性を変更する必要があります。J2EE アプリケーションを配備する個々の担当者が、トランザクション属性を指定する必要はありません。
エンタープライズ Bean 全体、または個々のメソッドのトランザクション属性を指定できます。メソッドと Bean に別々の属性を指定した場合は、メソッドの属性が優先されます。個々のメソッドの属性を指定する場合は、Bean のタイプによって必要条件が異なります。セッション Beans では、ビジネスメソッドの属性を定義する必要がありますが、create メソッドの属性を指定できません。エンティティ Beans では、ビジネスメソッド、create メソッド、remove メソッド、および検索メソッドのトランザクション属性が必要です。メッセージ駆動型 Beans では、onMessage メソッドのトランザクション属性 (Required か NotSupported のどちらか) が必要となります。
コンテナ管理トランザクションのロールバック
コンテナ管理トランザクションのロールバックには、次の 2 つの方法があります。1 つ目の方法は、システム例外がスローされた場合に、コンテナが自動的にトランザクションをロールバックする方法です。2 番目の方法は、EJBContext インタフェースの setRollbackOnly メソッドを呼び出すことによって、Bean メソッドがコンテナにトランザクションのロールバックを指示する方法です。Bean がアプリケーション例外をスローした場合は、自動的なロールバックは行われませんが、setRollbackOnly の呼び出しによってロールバックを起動できます。
次の例では、BankEJB の transferToSaving メソッドが setRollbackOnly メソッドを呼びだしています。バランスチェックが負の場合、transferToSaving は setRollBackOnly を呼び出し、アプリケーション例外 (InsufficientBalanceException) をスローします。updateChecking メソッドと updateSaving メソッドはデータベーステーブルを更新します。更新に失敗すると、これらのメソッドは SQLException をスローし、transferToSaving メソッドは EJBException をスローします。EJBException はシステム例外であるため、コンテナが自動的にトランザクションをロールバックします。transferToSaving メソッドのコードを次に示します。
public void transferToSaving(double amount) throws
InsufficientBalanceException {
checkingBalance -= amount;
savingBalance += amount;if (checkingBalance < 0.00) {
context.setRollbackOnly();throw new InsufficientBalanceException();
}
try {
updateChecking(checkingBalance);updateSaving(savingBalance);
} catch (SQLException ex) {
throw new EJBException
("Transaction failed due to SQLException: "
+ ex.getMessage());
}
}コンテナは、トランザクションのロールバック時に、トランザクション内の SQL 呼び出しによって加えられたデータ変更を元に戻します。ただし、エンティティ Beans の場合のみ、コンテナはインスタンス変数に加えられた変更を元に戻します。その場合は、エンティティ Beans の ejbLoad メソッドを自動的に呼び出して、データベースからインスタンス変数を読み込みます。セッション Beans では、ロールバックが発生したときに、トランザクション内で変更されたすべてのインスタンス変数を明示的にリセットする必要があります。セッション Beans のインスタンスをリセットするもっとも簡単な方法は、SessionSynchronization インタフェースを実装することです。
コマンド行インタフェースを通じてトランザクション ID を渡すことにより、トランザクションをロールバックすることもできます。詳細については、「コマンド行インタフェースを使用したトランザクションの管理」を参照してください。
セッション Beans のインスタンス変数の同期化
オプションで設定できる SessionSynchronization インタフェースでは、インスタンス変数とデータベース内の対応する値の同期をとることができます。コンテナは、トランザクションの主要ステージごとに SessionSynchronization のメソッド (afterBegin、beforeCompletion、および afterCompletion) を呼び出します。
afterBegin メソッドは、新しいトランザクションが開始されたことをインスタンスに知らせます。コンテナは、トランザクション内で最初のビジネスメソッドを呼び出す前に afterBegin を呼び出します。afterBegin メソッドは、データベースからインスタンスを読み込むのに適しています。たとえば、BankBean クラスは、次のように afterBegin メソッドで checkingBalance 変数と savingBalance 変数を読み込みます。
public void afterBegin() {
System.out.println("afterBegin()");
try {
checkingBalance = selectChecking();
savingBalance = selectSaving();
} catch (SQLException ex) {
throw new EJBException("afterBegin Exception: " +
ex.getMessage());
}
}コンテナは、ビジネスメソッドの完了後、トランザクションをコミットする直前に beforeCompletion メソッドを起動します。beforeCompletion メソッドは、セッション Bean が (setRollbackOnly を呼び出して) トランザクションをロールバックする最後の機会です。インスタンス変数の値によってデータベースがまだ更新されていない場合、セッション Bean は beforeCompletion メソッドでその処理を実行できます。
afterCompletion メソッドは、トランザクションが完了したことを示します。このメソッドは 1 つのブール型パラメータを持ち、その値は、トランザクションがコミットされた場合は true、ロールバックされた場合は false となります。ロールバックが発生した場合、セッション Bean は、afterCompletion メソッドでデータベースに基づいてインスタンス変数を更新できます。
public void afterCompletion(boolean committed) {
System.out.println("afterCompletion:" + committed);
if (committed == false) {
try {
checkingBalance = selectChecking();
savingBalance = selectSaving();
} catch (SQLException ex) {
throw new EJBException("afterCompletion SQLException:
" + ex.getMessage());
}
}
}コンテナ管理トランザクションで使用できないメソッド
コンテナが設定するトランザクション境界を侵害する可能性のあるメソッドを呼び出すことはできません。禁止されているメソッドは、次のとおりです。
- java.sql.Connection のコミットメソッド、setAutoCommit メソッド、およびロールバックメソッド
- javax.ejb.EJBContext の getUserTransaction メソッド
- javax.transaction.UserTransaction のすべてのメソッド
ただし、Bean 管理トランザクションで境界を設定する場合は、これらのメソッドを使用できます。
Bean 管理トランザクション
Bean 管理トランザクションでは、セッション Bean またはメッセージ駆動型 Bean のコードでトランザクションの境界を明示的に指定します。エンティティ Bean では、Bean 管理トランザクションではなく、コンテナ管理トランザクションを使用する必要があります。コンテナ管理トランザクションを使用する Bean では、コーディングが少なくてすみますが、次の制限があります。メソッドの実行中は、1 つのトランザクションだけに関連付けるか、トランザクションには一切関連付けないかのどちらかしかありません。この制限によって Bean のコーディングが難しくなる場合は、Bean 管理のトランザクションを使用することを検討してください。
次の擬似コードでは、Bean 管理トランザクションの使用により得られる細かい制御を示しています。この擬似コードでは、さまざまな条件をチェックすることにより、ビジネスメソッドで異なるトランザクションを起動または停止します。
begin transaction
...
update table-a
...
if (condition-x)
commit transaction
else if (condition-y)
update table-b
commit transaction
else
rollback transaction
begin transaction
update table-c
commit transactionトランザクションサービスの管理
トランザクションの管理には、管理インタフェースまたはコマンド行インタフェースを使用できます。
この節には次の項目があります。
管理インタフェースを使用したトランザクションの管理
管理インタフェースを使用すると、監視の有効化、ログレベルの設定、およびトランザクションに関する詳細なオプションの設定を行うことができます。
リカバリポリシーやタイムアウトなど、インスタンス全体のトランザクションサービス属性を制御できます。管理インタフェースで指定したプロパティおよび設定は、server.xml ファイルに保存されます。
トランザクションサービスオプションの設定を行うには、次の手順に従います。
- 管理インタフェースの左側のペインで、変更するトランザクション設定の Sun ONE Application Serverインスタンスツリーを展開します。
- 表示された J2EE サービスの一覧から「トランザクションサービス」を選択します。管理インタフェースの右側のペインに、トランザクションサービスのオプションの設定用のウィンドウが表示されます。
トランザクションサービスのオプションの設定
- トランザクションの監視を有効にするには、「監視を有効」チェックボックスにチェックマークをつけます。次の表では、監視できる Java トランザクションサービスの機能を示します。
- 「ログレベル」ドロップダウンリストから、トランザクションに設定するログレベルを選択します。ログレベルとその組み込み方法に関する詳細については、「ログの使用」を参照してください。
- 「再起動で回復」のチェックボックスにチェックマークをつけて、失敗したトランザクションをサーバーの再起動時に復旧するよう設定します。トランザクションのコミットプロトコル中の重要なポイントでリソースにアクセスできなくなった場合、トランザクションは完了せず、トランザクションログファイルに残ることがあります。このチェックボックスにチェックマークをつけた場合、サーバーは再起動時に未完了のトランザクションの復旧を試みます。関係するリソースにアクセスできない状態が続いていると、サーバーの再起動に時間がかかることがあります。デフォルトでは、このチェックボックスにはチェックマークがつけられていません。
- コンテナ管理トランザクションを使用するエンタープライズ Beans では、「トランザクションタイムアウト」の値を設定することにより、トランザクションのタイムアウト間隔を制御できます。
このプロパティ値を 0 に設定すると、トランザクションはタイムアウトしません。
「トランザクションタイムアウト」フィールドに、トランザクションのタイムアウト間隔を指定します。指定された時間内にトランザクションが完了しないと、トランザクションはロールバックされます。この属性の設定値が 0 の場合、トランザクションはタイムアウトしません。
- 「トランザクションログの位置」フィールドに、ログファイルを保存するディレクトリの絶対パスを指定します。トランザクションログの新しいディレクトリを有効にするには、サーバーを再起動する必要があります。
- 「特殊な結果判別」ドロップダウンボックスで、トランザクションに適用する特殊な結果判別を選択します。表示されたオプションから「Commit」または「Rollback」を選択して、アプリケーションサーバーが未確定トランザクションの復旧中に結果を判別できない場合に行う処理を指定します。「特殊な結果判別」を「Rollback」に設定すると、アプリケーションサーバーはトランザクションをロールバックします。場合によっては、未確定トランザクションをコミットしたほうが良い場合もあります。
- 「キーポイント間隔 (トランザクション数)」フィールドに、ログ内でのキーポイント間のトランザクション数を指定します。キーポイント処理によって、完了トランザクションのエントリが削除され、トランザクションログファイルが圧縮さえるため、トランザクションログファイルのサイズが小さくなります。この属性の値を大きくすると、トランザクションログファイルのサイズが大きくなりますが、キーポイント処理が少なくなるため、パフォーマンスが向上する可能性があります。小さい値 (たとえば 100) にすると、ログファイルのサイズは小さくなりますが、キーポイント処理の頻度が増えるため、パフォーマンスがわずかに低下します。
コマンド行インタフェースを使用したトランザクションの管理
次の各項目で説明するように、コマンド行インタフェース (CLI) を使用してデータベーストランザクションの管理と監視を行うことができます。
各項目では、コマンド行インタフェースを使用してトランザクションを管理する方法と監視する方法について説明します。
実行中トランザクションの一覧表示
マルチモードでユーザー名とパスワードを設定済みの場合、次のコマンドを使用して、実行中のトランザクションに関するデータを取得できます。
- asadmin> get --monitor <instanceName>.transaction-service.inflight-tx
次のような複数行の結果が表示されます。
Transaction Id State Elapsed Time(ms)
txnid1 Prepared 20
txnid2 Active 100
txnid3 Active 120
... ... ...
トランザクションの管理
実行中トランザクションの一覧表示の例で、txn-ids、txnid2、および txnid3 の各トランザクション ID を使用して、トランザクションをロールバックすることを考えます。選択したトランザクションをロールバックするためのコマンドは、次の例のようになります。
asadmin> set --monitor <instanceName>.transaction-service.rollback-list=txnid2,txnid3
トランザクションサービスの凍結
トランザクションサービスを凍結するには、次のコマンドを実行します。
asadmin> set --monitor <instanceName>.transaction-service.freeze=true
トランザクションサービスが凍結されると、アプリケーションサーバーのトランザクションマネージャは実行中のトランザクションを中断します。本稼働のシステムでは、凍結処理はお勧めできません。
トランザクションサービスの凍結を解除するには、次のコマンドを実行します。
asadmin> set --monitor <instanceName>.transaction-service.freeze=false
トランザクションサービスが再び動作すると、システムは停止していた状態から処理を継続します。システムが長時間凍結状態にあると、データベース接続がタイムアウトして、トランザクションがロールバックする可能性があります。
トランザクションの監視
実行中のトランザクションなど、トランザクションに関する監視データを取得するには、次のコマンドを実行します。
asadmin> get --monitor <instanceName>.transaction-service.*
コマンドの実行時にアクティブなトランザクションがなかった場合は、次のような結果が得られます。
total-tx-completed = 5
total-tx-rolledback = 2
total-tx-inflight = 0
isFrozen = false
tx-inflight = No active transactions found.
コマンドの実行時にアクティブなトランザクションが見つかった場合は、次のような結果が得られます。
total-tx-completed = 5
total-tx-rolledback = 2
total-tx-inflight = 2
isFrozen = false
tx-inflight =
Transaction Id State Elapsed Time(ms)
txnid1 Prepared 500
txnid2 Active 360