13.9. Total Order ベースのコミットプロトコル

トランザクションが終了すると、Data Grid はトランザクション (およびその変更) を合計順に送信します。これにより、関連するすべての Data Grid ノードですべてのトランザクションが同じ順序で配信されます。その結果、トランザクションが配信されると、同じ状態 (有効な場合) で決定的な書き込みスキューチェックが実行され、同じ結果 (トランザクションのコミットまたはロールバック) が発生します。

図13.3 1 フェーズコミット

上の図は、3 つのノードがある高レベルの例を示しています。Node1 と Node3 はそれぞれ 1 つのトランザクションを実行しており、両方のトランザクションが同じキーに書き込むことを想定できます。より興味深いものにするために、図の最初の色付きの円で表される、両方のノードが同時にコミットしようとすると仮定します。青い 円はトランザクション tx1、緑 はトランザクション tx2 を表しています。どちらのノードも、トランザクションの変更とともに、合計順序でリモート呼び出しを実行します(to-send)。この時点で、すべてのノードが同じ配信順序で同意します (例: tx1 の後に tx2 が続きます)。次に、各ノードは tx1 を提供し、検証を実行し、変更をコミットします。tx2 についても同じステップが実行されますが、この場合検証に失敗し、トランザクションは関係するすべてのノードでロールバックされます。

最初のフェーズでは、合計順に変更を送信し、書き込みスキューチェックが実行されます。書き込みスキューチェックの結果は、発信者に返されます。すべてのキーが正常に検証されたことを確認するとすぐに、TransactionManager に正の応答が付与されます。一方、負の応答を受信すると、TransactionManager に負の応答が返されます。最後に、トランザクションは TransactionManager リクエストに応じて 2 番目のフェーズでコミットまたは中止されます。

図13.4 2 フェーズコミット

上の図は、最初の図で説明したシナリオを示していますが、2 つのフェーズを使用してトランザクションをコミットします。tx1 が配信されると検証が実行され、TransactionManager に応答します。次に、TransactionManager が tx1 の 2 番目のフェーズをリクエストする前に、tx2 が配信されると仮定します。この場合、tx2 はキューに入れられ、tx1 が完了した場合にのみ検証されます。最終的に、tx1 の TransactionManager は 2 番目のフェーズ（コミット）を要求し、すべてのノードが tx2 の検証を自由に実行できます。

現在、トランザクションリカバリー は Total Order ベースのコミットプロトコルでは使用できません。

簡略化のため、Total Order ベースコミットプロトコルは、現在の状態遷移のブロッキングバージョンを使用しています。主な相違点は以下のとおりです。

これにより、状態遷移と、すべてのノードであるトランザクション配信間の同期が可能になります。ただし、新しい参加者に関連する新しい合計順序を見つけるには、トランザクションは状態遷移の開始前に送信され（つまり、状態遷移の開始後に送信される）再送信する必要があります。

図13.5 トランザクション中のノード参加

上の図は、ノードの参加 を示しています。シナリオでは、tx2 は topologyId=1 で送信されますが、受信時に topologyId=2 にあります。そのため、トランザクションは新規ノードに関連する再送信されます。