監査/履歴テーブルの目的で、CONTEXT_INFO を使用してユーザー名を削除トリガーに渡しています。CONTEXT_INFO の範囲を理解し、潜在的な競合状態が発生しているかどうかを確認しようとしています。
各データベース テーブルには、削除を処理するストアド プロシージャがあります。削除ストアド プロシージャは、userId をパラメーターとして受け取り、CONTEXT_INFO を userId に設定します。次に、削除トリガーが CONTEXT_INFO を取得し、それを使用して、行を削除したユーザーを示す監査テーブルを更新します。
質問は、異なるユーザーからの 2 つの削除ストアドプロシージャが同時に実行されている場合、ストアドプロシージャの 1 つに設定された CONTEXT_INFO が、他のストアドプロシージャによって起動されたトリガーによって消費されるかどうかです。
私はこの記事を見ましたhttp://msdn.microsoft.com/en-us/library/ms189252.aspxしかし、SQL Server のセッションとバッチの範囲が明確ではありません。これがこの記事が役に立つかどうかの鍵です。
コードを投稿したいのですが、現時点では時間が足りません。十分に明確でない場合は後で編集します。
ご協力いただければ幸いです。
ベストアンサー1
コンテキスト情報にはスコープ（言語変数のスコープという意味）がなく、セッションの存続期間に縛られています。一度設定されると、コンテキスト情報は接続が閉じられる（セッションが終了する）か、新しい値が設定されるまで、設定された値のままです。セッションでの実行はいつも順次実行の場合、同時実行の問題はありません。
プロシージャでコンテキスト情報を設定すると、そのセッションでその後実行されるトリガーには、新しく設定されたコンテキスト情報の値が表示されます。提案されているように、コンテキスト情報にユーザー ID 値を設定し、それをトリガーで使用することは、コンテキスト情報の使用の典型的な例であり、基本的に同時実行性はないため、同時実行性に関して完全に安全です。ストアド プロシージャでコンテキスト情報を設定し、そのプロシージャで発生する削除によって実行されるトリガーでそれに依存する予定の場合、バッチはまだ終了していないため、リンクした記事によると、DMVsys.dm_exec_requestsまたはCONTEXT_INFO()関数から conetxt 情報を取得します。まだプッシュされていません。プッシュされるのはsys.dm_exec_sessions、ストアド プロシージャを終了し、サーバーに送信された T-SQL バッチ内の他の呼び出し (「要求」) を完了した後のみです。