複数のレコードを持つ Azure SQL のテーブルがあります。このテーブルのデータは、複数の読み取り/書き込みメソッドを実装する API レイヤー (エンティティ フレームワークに基づく) を介して公開されます。この API レイヤーは、複数のインスタンスをサポートする worker ロール内にカプセル化されています。異なるクライアント マシンで同時に実行できるアプリケーション (Web ロールではなく、デスクトップ アプリ) があります。このアプリケーションは、前述の API を使用して 2 つの特定の呼び出しを行います。1 つは読み取り、もう 1 つは書き込みです。どちらの呼び出しも、Azure SQL テーブルの同じレコードにアクセスします。複数のクライアントがアプリケーションを使用して同じレコードを読み取ろうとするのを防ぐロック メカニズムの実装を検討しています。ただし、このレコード レベルの読み取りロックは、その 1 つの特定の読み取り呼び出しが行われた場合にのみ適用する必要があります (API によって公開された多数の中から)。レコードをロックする方法を見つけましたが、特定の呼び出しに固有のこのロックを実装する方法がわかりません。API を実装する worker ロールで複数のインスタンスが実行されていることを考慮すると、これはさらに複雑になります。
これまでに検討したいくつかのアイデア：
- ストアド プロシージャ: Entity Framework - Read Lock on Record。これにより、特定の読み取り呼び出しに対してのみ行をロックするという問題が発生します。
- アプリケーションが使用する API の読み取り呼び出しでのクリティカル セクション ロック。ただし、ワーカーの複数のインスタンスが実行されている場合、クリティカル セクションのロックはインスタンス レベルでのみ行われるため、これは役に立ちません。
- 最初の読み取りが行われたときに true としてマークされる追加の IsProcessing 列を使用します。これは、アイデア 1 および/またはアイデア 2 と組み合わせて使用できます。
- API で使用している read 呼び出しをリファクタリングして、行レベル ロックを実装します。私のアプリケーションはこの特定の読み取り呼び出しを使用する唯一のアプリケーションであるため、これが可能な解決策になる可能性がありますが、他の API 呼び出しからの他の読み取りは引き続き成功するはずなので、この呼び出しに対してのみロックを有効にするにはどうすればよいでしょうか...ロジスティクスもありますこのアイデアは、可能であれば実装したくない絶対的な最後の手段です。
任意のポインタをいただければ幸いです。
アップデート：
私のアプリケーションが使用する特定の読み取り呼び出しでミューテックスを使用することは、可能な解決策のようです。