第25章 トランザクションのセットアップ

25.1. トランザクション

トランザクションは、相互に依存しているか、または関連のある操作またはタスクのコレクションで構成されています。単一トランザクション内のすべての操作が成功しないと、トランザクションの全体の成功にはつながりません。トランザクション内のいずれかの操作が失敗すると、トランザクションは全体として失敗し、すべての変更をロールバックします。トランザクションは、大規模な操作の一部として一連の変更を処理する場合にとくに役立ちます。
Red Hat JBoss Data Grid では、トランザクションはライブラリーモードでのみ利用可能です。

25.1.1. トランザクションマネージャーについて

Red Hat JBoss Data Grid では、トランザクションマネージャーは、単一または複数のリソースにまたがってトランザクションを調整します。トランザクションマネージャーの役割には以下が含まれます。
  • トランザクションの開始および終了
  • 各トランザクションについての情報の管理
  • トランザクションが複数リソースにまたがって動作する際のトランザクションの調整
  • 変更のロールバックによる、失敗したトランザクションからのリカバリー

25.1.2. XA リソースおよび同期

XA リソースは独立したトランザクション要素です。準備段階で (詳細については、「2 相コミット (2PC) について」を参照)、XA リソースは、値が OK または ABORT のいずれかの投票を返します。トランザクションマネージャーがすべての XA リソースから OK 投票を受信する場合、トランザクションはコミットされ、それ以外の場合にはロールバックされます。
同期は、トランザクションのライフサイクルにつながるイベントについての通知を受信するリスナーの 1 つのタイプです。同期は、操作の終了前後にイベントを受信します。
リカバリーが必要ではない場合、完全な XA リソースとして登録する必要はありません。同期の利点には、同期により、トランザクションマネージャーが、その他の 1 つのリソースのみがそのトランザクションでリストされる 1 相コミット (1PC) で 2 相コミット (2PC) を最適化できる点があります (最終リソースコミット最適化)。これにより、同期をより効率的にすることができます。
ただし、Red Hat JBoss Data Grid 内の準備段階で操作が失敗する場合、トランサクションはロールバックされず、トランザクションにより多くの参加者が存在する場合、それらはその失敗を無視し、コミットできます。さらに、コミット段階で発生するエラーは、トランザクションをコミットするアプリケーションコードに伝搬されません。
デフォルトで、JBoss Data Grid は同期としてトランザクションに登録されます。

25.1.3. 楽観的トランザクションと悲観的トランザクション

悲観的トランザクションは、キー上で最初の書き込み操作が実行される際にロックを取得します。キーがロックされた後は、このトランザクションがコミットされるか、またはロールバックされるまでその他のトランザクションはキーを変更することができません。デッドロックを回避するために正しい順番でロックを取得できるかどうかは、アプリケーションコードによります。
楽観的トランザクションの場合、ロックはトランザクションの準備時間に取得され、トランザクションがコミット (またはロールバック) するまで保持されます。さらに、Red Hat JBoss Data Grid は、トランザクション内の変更されたすべてのエントリーについてキーを自動的にソートし、ロックされているキーの順序が正しくないために生じるデッドロックを回避します。この結果は以下のようになります。
  • トランザクションの実行時に送信されるメッセージが少なくなる
  • ロックの保持期間が短くなる
  • スループットが改善する

注記

読み取り操作ではロックを一切取得しません。オンデマンドで読み取り操作のロックを取得することは、この操作と共に FORCE_WRITE_LOCK フラグを使用した場合の悲観的トランザクションでのみ可能になります。

25.1.4. 書き込みスキューのチェック

エントリーの共通のユースケースとして、エントリーはまず読み取られ、その後トランザクションで書き込みが行なわれます。ただし、3 つ目のトランザクションが、これら 2 つの操作の間にエントリーを変更する可能性があります。このような状況を検出し、トランザクションをロールバックするために、Red Hat JBoss Data Grid は、エントリーのバージョン管理と書き込みスキューのチェックを行います。変更されたバージョンがトランザクション時に最後に読み取られたバージョンと同じでない場合、書き込みスキューチェックは例外をスローし、トランザクションはロールバックされます。
書き込みスキューのチェックを有効にするには、REPEATABLE_READ の分離レベルが必要です。さらに、クラスターモード (ディストリビューションモードまたはレプリケーションモード) で、エントリーのバージョン管理をセットアップします。ローカルモードの場合、エントリーのバージョン管理は不要です。

重要

楽観的トランザクションの場合、書き込みスキューのチェックは、(アトミックな) 条件操作で必要になります。

25.1.5. 複数のキャッシュインスタンスにわたるトランザクション

各キャッシュは個別のスタンドアロン Java Transaction API (JTA) リソースとして動作します。ただし、コンポーネントは最適化のために Red Hat JBoss Data Grid で内部的に共有できますが、この共有は、キャッシュの Java Transaction API (JTA) Manager との対話方法には影響を与えません。