设置CONTEXT_INFO选择context_info（），锁定

Question

想象一下表T的用法如下：

在时间T0：SPID 1： 开始交易    ...    插入T（...）值（...）;    ... 提交;

在时间T1 SPID 2： 开始交易    从T中选择*，其中C = cval;    ... 提交;

假设事务隔离级别设置为可序列化。 另外假设SPID1设法在时间T1之前在T上采用TABLOCKX，并且SPID1正在执行长事务，最终使SPID2等待T上的TABLOCKX被释放。

现在，请考虑使用CONTEXT_INFO而不是T

的相同方案

在时间T0：SPID 1： 开始交易    ...    SET CONTEXT_INFO = 0xFF;    ... 端;

在时间T1 SPID 2： 开始交易    select context_info（）;    ... 端;

同样，假设事务隔离级别设置为可序列化。

我知道CONTEXT_INFO是每个连接。我不认为SPID 1和SPID 2正在使用CONTEXT_INFO进行通信。它们是完全独立的，假设它们同时使用CONTEXT_INFO用于单独的目的。

现在，由于TABLOCKX而无需等待即可执行选择。 事实上，由于使用CONTEXT_INFO锁定，我无法引发任何类型的等待。

这对我很好，因为我需要这种行为。我的问题是，即使CONTEXT_INFO应该是“SPID表示”中sql server中的内存变量，它似乎存储在MSSQL2000上的一个名为master.dbo.sysprocesses的表中（select context_info（）在这里不起作用），以及MSSQL Server更高版本的sys.sysprocesses。

这些表是否与锁定方面的所有其他表一样，或者这些表只是不符合与其他表相同规则的变量的窗口吗？

另一件让我感到震惊的是，spt_values上的TAB类型的IS模式锁定被设置为context_info和KEY类型，RangeS-S模式锁定在读取sysprocesses时。 但是，由于这是一个内部对象，所以我没有把握的真正后果是什么。

请赐教。

此致 Jens Nordenbro

---

• 我不够清楚，我知道CONTEXT_INFO是每个连接。我不认为SPID 1和SPID 2正在使用CONTEXT_INFO进行通信。它们是完全独立的，假设它们使用CONTEXT_INFO用于不同的目的。我只是害怕他们需要相同的锁资源。这就是真正的问题所在。
• 你的意思是什么？

Answer 1

• CONTEXT_INFO是每个连接
• sysprocesses不是真正的表，你不能使用HINT（例如WITH TABLOCKX）

在OP的其他答案之后编辑：

sysprocesses没有会影响代码的锁或争用。也就是说，您对CONTEXT_INFO的使用不会受到sysprocesses内部任何内容的影响。

至于“真实桌子”......根据OBJECTPROPERTY的“TableIsFake”测试，它是一个“假表”：

  

表不真实。它由SQL Server数据库引擎按需内部实现。