SQL Serverでアプリロックリクエストをキャンセルするにはどうすればよいですか？

sp_getapplockストアドプロシージャは、次の戻り値があります。

0：ロックは同期的に正常に許可されました。
1：他の互換性のないロックが解放されるのを待った後、ロックが正常に許可されました。
-1：ロック要求がタイムアウトしました。
-2：ロック要求はキャンセルされました。
-3：ロック要求がデッドロックの犠牲者として選択されました。
-999：パラメーターの検証またはその他の呼び出しエラーを示します。

sp_getapplockデータアクセスレイヤーで呼び出すためのラッパーを書いています。どのような状況で-2が返されるのかを知りたいので、説明的で役立つ例外をスローできます。-1と-3の戻り値の意味は明らかであり、これらの値が返されるテスト条件を簡単に作成できます。どのようにして-2の戻り値を取得できますか？

sp_getapplockラッパーsys.xp_userlock プロシージャのソースを見ると、-999を除くすべての戻り値は、基になる内部ストアドプロシージャに由来しています。要求がアテンションイベント（クライアントクエリタイムアウトまたは明示的なクライアントクエリキャンセル）によってキャンセルされた場合、内部プロシージャは-2を返します。ただし、ステートメントsp_getapplockを含め、バッチがキャンセルされた後は、それ以上のコードは実行されませんRETURN。その結果、-2戻りコードが内部的に返される場合がありますが、クライアントが値を取得する実用的な方法はありません。

この理論が正しいと仮定すると、そもそもリクエストをキャンセルしたのはクライアントであるため、-2をよりわかりやすいメッセージに変換することに値はありません。

これを確認するために、デバッガーでSQLデータベースエンジンのコードをステップ実行して、ポールに任せます。

sp_getapplockは、物理オブジェクトではなくセマフォにロックを作成します（MSDNによる）。同じ文字列で互換性のないロックモードのsp_getapplockである場合にのみ、別のプロセスをブロックします。

したがって、ロック要求は、より高い特権を持つユーザーがロックをキャンセルする、サーバープロセスがロックをキャンセルする、ストアドプロシージャを実行しているユーザー、または管理者がロックプロセスを強制終了するなどの状況でキャンセルされます。説明は、「システムまたは別のユーザーによってロックがキャンセルされた」可能性があります。ロックをキャンセルした実際のプロセス/ユーザーをどのように判断するかわかりません。

sp_releaseapplockと呼ばれる対応するリリースアプリケーションロックストアドプロシージャがあります。

これらのストアドプロシージャを使用してアプリケーションフローを制御することについて、SQL Server Centralで「SQLのmutex」という混乱したタイトルの記事をここに書きました。