8.9. 順序ベースのコミットプロトコルの合計

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

図8.3 1 フェーズコミット

上の図は、3 つのノードで構成される高レベルの例を示しています。Node1 および Node3 は各トランザクションを 1 つ実行しており、両方のトランザクションが同じキーに書き込むことを仮定します。より複雑なものにするために、両方のノードが、最初の色付きの円で表されているように、両方のノードが同時にコミットしようとすることを仮定します。青い 円はトランザクション tx1 とトランザクション tx2 を表します。両方のノードは、トランザクションの変更とともに合計順序（送信）でリモート呼び出しを行います。この時点で、すべてのノードは同じ配信順序で合意します（例： tx1 の後に tx2 が続きます）。次に、各ノードは tx1 を提供し、検証を実行し、変更をコミットします。tx2 に同じ手順が実行されますが、この場合検証に失敗し、トランザクションは関係するすべてのノードでロールバックされます。

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

図8.4 2 フェーズコミット

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

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

分かりやすくするために、合計順序ベースのコミットプロトコルは、現在の状態遷移のブロッキングバージョンを使用します。主な違いは以下のとおりです。

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

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

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