我有一组验证来确定要使用有效状态代码将记录插入数据库中，我们面临的问题是，许多用户在同一时间发出请求，并且在另一笔交易的中间发生另一笔交易，并且都插入了有效的代码。状态，这是不应该的。它应该返回一个错误，表明记录已经存在，可以通过简单的查询轻松地处理它，但是在特定情况下，我们允许他们插入重复项，我尝试了sp_getapplock，它虽然可以解决我的问题，但是却在很大程度上损害了性能。是否有任何最佳方式来处理并发请求？
谢谢。
sp_getapplock是您可以采取的最佳，最随意的锁。它的功能更像lockOOO编程中的关键字。基本上，您为资源命名，给它一个范围（proc或事务），然后锁定它。几乎没有什么可以绕过那个锁，这就是为什么它可以解决您的比赛条件。对于您尝试执行的操作，它可能也太疯狂了。
想到的第一个代码/体系结构想法是重组该表。我将假设您的更新量很高，否则您将不会遇到这些违规行为。您可以简单地使用try / catch块，并使catch块在PK违例时重试。笨拙，但可能会成功。
接下来，您可以考虑更改全天接收此更新流的表的结构。使该表primary keyed脱离一个标识列，几乎没有其他东西。插入物将很快闪电，因此任何遮挡都可以忽略不计。然后，您可以将这些数据分批移动到更适合批处理的表中（与尝试实时批处理相反）
还有一系列事务隔离设置，这些设置可调整SQL的常规锁定系统以支持不同的变体（无论是在批处理级别还是通过查询提示进行内联。我会仔细阅读这些内容，但您可以考虑使用序列化隔离。各种设置将强制执行不同的运行时规则，以满足您的需求。
另外，请务必检查您的交易。您可能希望将地狱锁定在该表之外（并且可能在其他操作期间），但是一旦这种需求消失了，锁定也应该锁定。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句