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

Red Hat JBoss Data Grid では、トランザクションマネージャーは、単一または複数のリソースにまたがってトランザクションを調整します。トランザクションマネージャーの役割には以下が含まれます。

XA リソースは独立したトランザクション要素です。準備段階で (詳細については、「2 相コミット (2PC) について」を参照)、XA リソースは、値が OK または ABORT のいずれかの投票を返します。トランザクションマネージャーがすべての XA リソースから OK 投票を受信する場合、トランザクションはコミットされ、それ以外の場合にはロールバックされます。

同期は、トランザクションのライフサイクルにつながるイベントについての通知を受信するリスナーの 1 つのタイプです。同期は、操作の終了前後にイベントを受信します。

リカバリーが必要ではない場合、完全な XA リソースとして登録する必要はありません。同期の利点には、同期により、トランザクションマネージャーが、その他の 1 つのリソースのみがそのトランザクションでリストされる 1 相コミット (1PC) で 2 相コミット (2PC) を最適化できる点があります (最終リソースコミット最適化)。これにより、同期をより効率的にすることができます。

ただし、Red Hat JBoss Data Grid 内の準備段階で操作が失敗する場合、トランサクションはロールバックされず、トランザクションにより多くの参加者が存在する場合、それらはその失敗を無視し、コミットできます。さらに、コミット段階で発生するエラーは、トランザクションをコミットするアプリケーションコードに伝搬されません。

デフォルトで、JBoss Data Grid は同期としてトランザクションに登録されます。

悲観的トランザクションは、キー上で最初の書き込み操作が実行される際にロックを取得します。キーがロックされた後は、このトランザクションがコミットされるか、またはロールバックされるまでその他のトランザクションはキーを変更することができません。デッドロックを回避するために正しい順番でロックを取得できるかどうかは、アプリケーションコードによります。

楽観的トランザクションの場合、ロックはトランザクションの準備時間に取得され、トランザクションがコミット (またはロールバック) するまで保持されます。さらに、Red Hat JBoss Data Grid は、トランザクション内の変更されたすべてのエントリーについてキーを自動的にソートし、ロックされているキーの順序が正しくないために生じるデッドロックを回避します。この結果は以下のようになります。

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

書き込みスキューのチェックを有効にするには、REPEATABLE_READ の分離レベルが必要です。さらに、クラスターモード (ディストリビューションモードまたはレプリケーションモード) で、エントリーのバージョン管理をセットアップします。ローカルモードの場合、エントリーのバージョン管理は不要です。

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