8.4. スキューの書き込み
書き込みスキューは、2 つのトランザクションが独立して同時に同じキーの読み取りと書き込みを行うときに発生します。書き込みスキューの結果、両方のトランザクションは同じキーに対して更新を正常にコミットしますが、値は異なります。
ライブラリーモードでは、Red Hat Data Grid は自動的に書き込みスキューチェックを実行し、最適なトランザクションで REPEATABLE_READ 分離レベルのデータの整合性を確保します。これにより、Red Hat Data Grid はトランザクションの 1 つを検出し、ロールバックすることができます。
write-skew 属性はライブラリーモードで非推奨となりました。Remote Client/Server Mode では、この属性は有効な宣言ではありません。
LOCAL モードで動作する場合、書き込みスキューの確認は Java オブジェクト参照に依存して違いを比較します。これにより、書き込みスキューをチェックするための信頼性の高い技術が提供されます。
クラスター環境では、データをバージョン管理し、信頼できる書き込みのスキューチェックを行う必要があります。Red Hat Data Grid は、SIMPLE バージョン管理と呼ばれる EntryVersion インターフェースの実装を提供します。これは、エントリーが更新されるたびに増分される期間でサポートされます。
<versioning scheme="SIMPLE|NONE" />
<versioning scheme="SIMPLE|NONE" />
または
new ConfigurationBuilder().versioning().scheme(SIMPLE);
new ConfigurationBuilder().versioning().scheme(SIMPLE);
8.4.1. 悲観的トランザクションでのキーへの書き込みロックの強制 リンクのコピーリンクがクリップボードにコピーされました!
pessimistic トランザクションで write-skews を回避するには、Flag.FORCE_WRITE_LOCK を指定して読み取り専用でキーをロックします。
-
トランザクション以外のキャッシュでは、
Flag.FORCE_WRITE_LOCKは動作しません。get()呼び出しは、キーの値を読み取りますが、ロックをリモートで取得しません。 -
Flag.FORCE_WRITE_LOCKは、同じトランザクションでエンティティーが後で更新されるトランザクションと併用する必要があります。
Flag.FORCE_WRITE_LOCK の例については、以下のコードスニペットを比較してください。