私はAzureキャッシングが初めてで、1つの問題に直面しています。
最初にシナリオについて簡単に説明します。SQL Azure
アプリケーションのDBとして使用しています。待機時間の問題とスロットリングの問題を回避するために、Azure キャッシュ (Web ロールのコロケーション キャッシュ) を使用しています。Azure Caching を使用することで、DB からデータを 1 回だけフェッチし、それをキャッシュに保持して後で使用できるようにします。
キャッシュされたデータを使用しているため、ここでの課題は、DML 操作が実行されるたびに、いつでも SQL Azure DB と Azure キャッシュの間でデータを常に同期させることです。最初にDBを更新し、更新が成功した場合はキャッシュされたデータを無効にすることでこれを行っています。このアプローチは、通常のシナリオではうまく機能します。ただし、同時ユーザーが作業して更新を実行していると、問題があるようです。キャッシュ内のデータを更新する際に、悲観的同時実行モデルを使用しています。ここでは、一時的な再試行ポリシーを使用して再試行を確実に行います (1 秒の固定間隔で 5 回としましょう)。
サンプル コードは次のようになります。
Microsoft.Practices.TransientFaultHandling.RetryPolicy cacheRetryPolicy =
GetAzureCacheRetryPolicy();
cacheRetryPolicy.Retrying += TransientRetryManager.OnRetrying;
DataCacheLockHandle handle = null;
cacheRetryPolicy.ExecuteAction(() =>
{
try
{
object obj = cache.GetAndLock(key, TimeSpan.FromSeconds(1), out handle);
cache.PutAndUnlock(key, value, handle, expirationTime.Value, tags);
}
catch (DataCacheException ex)
{
if (ex.ErrorCode == DataCacheErrorCode.KeyDoesNotExist)
{
cache.Put(key, value, expirationTime.Value, tags);
}
else
{
//This means wait till the cache is released.
//Throwing from here will allow to retry with Transient
//handling retry policy.
throw ex;
}
}
}
ここで、待機回数 (6 としましょう) が再試行回数 (この場合は 5) を超えた場合を考えます。6 番目の順番になるまでに、再試行の試行はすでに終了しているため、最新の更新がある 6 番目の Wait はキャッシュでの更新に失敗します。
この問題を解決するには、キャッシュ キーのロックを取得している間にerrorcode
すべての待機をキューに入れる方法があります。objectlocked
誰でもこのケースを処理する最善の方法を提案できますか?