使用SQL Server作为资源锁定机制

您基本上是在描述基于队列的经典工作流,并且应该考虑使用 queue .

为了便于讨论,以下是您如何实现自己的愿望:

• 声明特定资源: SELECT ... FROM resources WITH (UPDLOCK, ROWLOCK) WHERE key = @key . 如果资源已被占用,将阻止。如果资源已声明,请使用锁定超时返回异常。 key 必须 索引和唯一性。
• 下一个可用资源: SELECT ... FROM resources WITH (UPDLOCK, ROWLOCK, READPAST) ORDER BY <accessorder> . 您必须定义order by来表示资源的首选项(最早、最高优先级等)
• 释放声称的资源: COMMIT 您的交易。

问题的关键是使用正确的锁提示,这种问题确实需要显式的锁提示来解决。updlock将充当“claim”锁。rowlock创建正确的粒度,防止服务器“优化”页面锁。readpass允许您跳过声明的资源。在行上放置updlock将锁定该行,并允许您稍后更新它,但会阻止其他操作,如将在锁定行上阻塞的普通读提交选择。不过,您的想法是无论如何都要更新行,这将放置一个不可避免的X锁。如果您想保持桌子的可用性,可以使用 app locks 相反,但是很难正确完成。您需要在资源的字符串描述符上请求一个应用程序锁,比如键值,或者 CHECKSUM 或者是钥匙的 %%LOCKRES%% 价值。app locks允许您通过在“session”范围请求app lock来将“claim”的范围从事务中分离出来,但是您必须手动释放claim(“transaction”范围的app locks在提交时被释放)。不过,抬头看看,有上千种方法可以用应用程序锁把自己的脚射死。

SQL Server有一个名为 sp_getapplock . 文档将其描述为

锁定应用程序资源。

客户机可以竞争已命名的锁(您给它指定您想要的名称),一旦锁定,就执行所需的操作。如果客户端崩溃,锁将自动释放。要以编程方式释放锁,可以调用 sp_releaseapplock

使用AppLocks的可定位解决方案

• 如果索赔人为空,请尝试使用相同的名称获取applock。
• 如果获得了applock,请使用您的clasent id更新该行。
• 一旦该行被声明,释放applock,因为没有其他客户端会尝试声明它,现在它已经被声明了。
• 完成后,将clasent更新为空