後書きローダー・アプリケーション設計に関する考慮事項

後書きローダーを実装する際は、保全性制約、ロックの振る舞い、パフォーマンスといった、いくつかの問題を考慮する必要があります。

アプリケーション設計に関する考慮事項

後書きサポートを使用可能にすることは簡単ですが、後書きサポートを扱うアプリケーションを設計する際には、注意すべき考慮事項があります。後書きサポートがない 場合、ObjectGrid トランザクションにバックエンド・トランザクションが包含されます。 ObjectGrid トランザクションはバックエンド・トランザクションの開始前に開始し、 バックエンド・トランザクションの終了後に終了します。

後書きサポートが 有効な場合、ObjectGrid トランザクションは、バックエンド・トランザクションが開始する前に 終了します。ObjectGrid トランザクションとバックエンド・トランザクション は切り離されます。

参照保全性の制約

後書きサポートで構成されているそれぞれのバックアップ・マップは、データをバックエンドにプッシュするための独自の後書きスレッドを持ちます。したがって、1 つの ObjectGrid トランザクションに さまざまなマップを更新するデータが含まれていても、バックエンドでは、 それぞれ異なるバックエンド・トランザクションでデータの更新が行われます。例えば、トランザクション T1 は マップ Map1 のキー key1 とマップ Map2 のキー key2 を更新するとします。マップ Map1 に対する key1 更新は、1 つのバックエンド・トランザクションでバックエンドに対して更新され、マップ Map2 に対する key2 更新は、異なる後書きスレッドにより別のバックエンド・トランザクションでバックエンドに対して更新されます。Map1 に保管されたデータと Map2 に保管されたデータがバックエンドでの外部キー制約などの関係を持つ場合、更新が失敗する可能性があります。

バックエンド・データベースの 参照保全性制約を設計するときは、順不同の更新に必ず対応できるようにしてください。

キュー・マップのロックの振る舞い

トランザクションの動作で他に大きく異なる点は、ロックの振る舞いです。 ObjectGrid は、PESSIMISTIC、OPTIMISITIC、および NONE の 3 つの 異なるロック・ストラテジーをサポートします。後書きキュー・マップは、 *バックアップ・マップに構成されているロック・ストラテジーに関係なく、ペシミスティック・ロック・ストラテジーを 使用します。キュー・マップのロックを取得する 操作には 2 つの異なるタイプがあります。
  • ObjectGrid トランザクションのコミット時、またはフラッシュ (マップ・フラッシュまたは セッション・フラッシュ) の発生時、トランザクションはキュー・マップ内のキーを読み取り、 キーに S ロックをかけます。
  • ObjectGrid トランザクションのコミット時、トランザクションは、 キーの S ロックを X ロックにアップグレードしようとします。
キュー・マップのこの余分な動作のため、 ロックの動作に少々違いがあります。
  • ユーザー・マップがペシミスティック・ロック・ストラテジーで構成されている場合、 ロックの動作にほとんど違いはありません。フラッシュまたはコミットが呼び出されるたび、 キュー・マップ内の同じキーに S ロックがかけられます。 コミット時間中、ユーザー・マップ内のキーに X ロックが取得されるだけでなく、キュー・マップ内のキーに対しても X ロックが取得されます。
  • ユーザー・マップが OPTIMISTIC または NONE ロック・ストラテジーで構成されている場合、 ユーザー・トランザクションは PESSIMISTIC ロック・ストラテジーのパターンに従います。フラッシュまたはコミットが呼び出されるたびに、キュー・マップ内の同じキーに対して S ロックが取得されます。コミット時間の間、同じトランザクションを使用するキュー・マップ内のキーに対して X ロックが設定されます。

ローダー・トランザクションの再試行

ObjectGrid は、2 フェーズ・トランザクションまたは XA トランザクションをサポートしません。後書きスレッドは、キュー・マップからレコードを除去して、バックエンドに対してそのレコードを更新します。トランザクションの最中にサーバーに障害が起こると、一部のバックエンドの 更新が失われる可能性があります。

後書きローダーは、失敗したトランザクションの書き込みを 自動的に再試行し、データ損失を防ぐために未確定 LogSequence をバックエンドに 送信します。このアクションを行うには、ローダーがべき等である必要があります。 この意味は、Loader.batchUpdate(TxId, LogSequence) が同じ値で 2 回呼び出されたとき、 それは適用された回数があたかも 1 回だったかのように、 同じ結果を返すということです。ローダー実装は、この機能を 使用可能にするため、RetryableLoader インターフェースを実装しなければなりません。詳しくは、API 資料を 参照してください。

後書きキャッシングのパフォーマンスに関する考慮事項

後書きキャッシング・サポートの場合、ローダー更新をトランザクションから除去することで、応答時間が改善されます。また、データベース更新が結合されるため、データベース・スループットも 増加します。データをキュー・マップから プルし、ローダーにプッシュされる後書きスレッドの導入によって 生じるオーバーヘッドを理解しておく必要があります。

予想される使用パターンおよび環境に基づいて、最大更新数または最大更新時間を調整する必要があります。最大更新カウントまたは最大更新時間の値が小さすぎると、後書きスレッドのオーバーヘッドが、その 利点を帳消しにするおそれがあります。これら 2 つのパラメーターに大きな値を 設定する場合も、データのキューイングに必要なメモリー使用が増え、 データベース・レコードが不整合になる時間が増加するおそれがあります。

最善のパフォーマンスを得るために、後書き関係のパラメーターは、以下の要因を考慮に入れて調整してください。
  • 読み取りトランザクションと書き込みトランザクションの比率
  • 同一レコード更新の頻度
  • データベース更新の待ち時間