sql-server - SQL Server 中 CONTEXT_INFO 的范围是什么？

Question

我正在使用 CONTEXT_INFO 将用户名传递给删除触发器，以用于审核/历史表。我正在尝试了解 CONTEXT_INFO 的范围以及我是否正在创建潜在的竞争条件。

我的每个数据库表都有一个存储过程来处理删除。删除存储过程将 userId 作为参数，并将 CONTEXT_INFO 设置为 userId。然后，我的删除触发器获取 CONTEXT_INFO 并使用它来更新审计表，该表指示谁删除了行。

问题是，如果来自不同用户的两个删除存储过程同时执行，其中一个存储过程中设置的 CONTEXT_INFO 是否可以被另一个存储过程触发的触发器使用？

我看过这篇文章http://msdn.microsoft.com/en-us/library/ms189252.aspx但我不清楚 SQL Server 中 session 和批处理的范围，这是本文有帮助的关键!

我会发布代码，但目前时间有限。如果还不够清楚，我稍后会进行编辑。

预先感谢您的帮助。

Answer 1

上下文信息没有范围(在语言变量范围的意义上)并且绑定(bind)到 session 生命周期。设置后，上下文信息将保持设置的值，直到连接关闭( session 终止)或设置新值。由于 session 上的执行始终是顺序的，因此不存在并发问题。

如果您在过程中设置上下文信息，则随后在该 session 上执行的任何触发器都将看到新设置的上下文信息值。按照您的建议，在上下文信息中设置用户 id 值，并在触发器中使用它是上下文信息使用的典型示例，并且在并发性方面是完全安全的，因为基本上没有并发性可言。如果您计划在存储过程中设置上下文信息，然后在由于所述过程中发生的删除而运行的触发器中依赖它，那么您的批处理尚未完成，因此根据您链接的文章，您将检索来自sys.dm_exec_requests DMV 或来自CONTEXT_INFO() 函数的conetxt 信息。它尚未被推送到 sys.dm_exec_sessions 中，只有在退出存储过程并完成发送到服务器的 T-SQL 批处理中的任何其他调用(“请求”)后才会发生这种情况。