1.7. サイト全体でのクライアント接続

クライアントが同時に同じエントリーに書き込むが、サイトが異なる場合は、Active/Active サイト設定でエントリーの競合が発生する可能性があります。

たとえば、クライアント B が NYC の "k1" に書き込むのと同時に、クライアント A は LON の "k1" に書き込みます。この場合、"k1" の値は LON と NYC とで異なります。レプリケーションの発生後、"k1" のどの値がどのサイトに存在するかは保証されません。

データの整合性を確保するために、Data Grid はベクトルクロックアルゴリズムを使用して、次の図のように、バックアップ操作中に競合するエントリーを検出します。

            LON       NYC

k1=(n/a)    0,0       0,0

k1=2        1,0  -->  1,0   k1=2

k1=3        1,1  <--  1,1   k1=3

k1=5        2,1       1,2   k1=8

                 -->  2,1 (conflict)
(conflict)  1,2  <--

ベクトルクロックは、エントリーへの書き込みごとにインクリメントするタイムスタンプのメタデータです。上記の例では、0,0 は、"k1" 上のベクトルクロックの初期値を表します。

クライアントは LON に "k1=2" を配置し、ベクトルクロックは 1,0 で、Data Grid はこれを NYC に複製します。その後、クライアントは NYC に "k1=3" を配置し、ベクタークロックは 1,1 に更新されます。Data Grid はこれを LON に複製します。

ただし、クライアントが NYC に "k1=8" を配置するのと同時に、クライアントが LON に"k1=5" を配置すると、Data Grid は競合するエントリーを検出します。これは、"k1" のベクター値が LON と NYC の間で厳密に大きかったり小さかったりしないためです。

競合するエントリーを見つけると、Data Grid は Java compareTo(String anotherString) メソッドを使用してサイト名を比較します。どのキーが優先されるかを決定するために、Data Grid は辞書式順序で他のキーよりも小さいサイト名を選択します。AAA という名前のサイトからのキーは、AAB という名前のサイトからのキーよりも優先されます。

同じ例に従って、"k1" の競合を解決するために、Data Grid は LON からの "k1" の値を使用します。これにより、Data Grid が競合を解決し、値を複製した後に、LON と NYC の両方で "k1=5" となります。

バックアップストラテジー

Data Grid は、非同期バックアップストラテジ (strategy=async) のみを使用して競合解決を実行します。

Active/Active 設定で同期バックアップストラテジーを使用することはできません。この設定では、同時書き込みがデッドロックになり、データが失われます。ただし、両方のサイトが異なるデータセットにアクセスする場合、Active/Active 設定で同期バックアップストラテジーを使用できます。この場合、同時書き込みによるデッドロックのリスクはありません。

クロスサイトマージポリシー

Data Grid は、以下を行うために Data Grid を設定するクロスサイトマージポリシーに加えて、XSiteEntryMergePolicy SPI を提供します。