什么是金融运营中的锁定、死锁问题？答案

【问题标题】：What are locking, deadlocking issues in financial operations?什么是金融运营中的锁定、死锁问题？
【发布时间】：2010-10-01 01:53:50
【问题描述】：

在当地的一家金融机构中，他们的程序员指责我表达了我的观点，即（他们的程序员痴迷于）（b）他们的 MS SQL Server 2005 数据库中的锁定问题对我来说没有多大意义。

如果财务操作从未更新、删除甚至不正确的操作（“交易”的一部分？）通过向数据库中插入（添加）新的更正记录来更正，那么可能出现的锁定、阻塞、死锁问题是什么？ ?
这在英语中的术语是什么？在其他语言中，它被称为 storno、stornoed (?) 操作/记录。

因此，据我了解，“交易”实际上永远不会回滚，也永远不会有不正确/不存在的记录，只有未实现的记录。

更新：
我用谷歌搜索了 storno，但找不到任何用英文定义或在英文文本中使用的结果。
我找到了 storno 的定义（拉丁字母）只有意大利语。
但是会计是在意大利发明的，许多意大利会计术语在其他语言中使用，例如，在俄罗斯会计（银行）中。
我还以为这是国际公认的财务运营会计惯例，不是吗？

更新 2：
S.Lott 给了我The way that transactions are reversed in an ERP application is a big deal! 的链接，告诉我 storn 是逆转交易。

嗯，这是不正确的。 Storno 不仅是交易，它是纠正错误操作的任何操作（交易的一部分），尽管 2 个操作组合起来可能看起来是逆向交易（由 2 个操作组成 - 对目标和源帐户进行贷记和借记）。

那么，storno 是不是世界范围内普遍的财务会计实践？

无论如何，我想避免讨论会计细节/技术/术语，并将问题限制在从不删除或更新记录的上下文中。

在这种情况下，锁定、阻塞、死锁、性能可能会出现哪些问题？

【问题讨论】：

【解决方案1】：

“Storno Transactions”或“Reversing Transactions”总结得很好。在很多地方。

不要将软件实施与会计混为一谈。一个合理的实现可以通过最少的锁定来实现。然而，这并不意味着什么。您可能会因为软件 (a) 设计不良和 (b) 由于设计不良而需要小心锁定而受到指责。

可能的问题是什么...？

由于我们不知道软件编写得有多好或多差，因此无法猜测。他们可能知道一些你不知道的关于他们的系统的事情。

一个简单的 storno 交易系统应该很容易实现。事实上，它应该是微不足道的。

如果在插入期间使用页级锁定，一对“仅插入”表仍可能遇到死锁。

表 A，第 1 页在事务 X 中有一个插入。

表 B，第 2 页在事务 Y 中插入。

表 B，第 2 页在事务 X 中有一个插入。

表 A，第 1 页在事务 Y 中有一个插入。

避免死锁的唯一方法是让整个系统使用单个表。或者将所有事务限制在一个表中。或者使用单个数据库范围的锁。

如果您有多个表操作（和页级锁定），那么即使使用仅插入操作，您仍然会遇到潜在的死锁。显然这种情况很少见，但仍有可能。

【讨论】：

"或者使用单个数据库范围的锁。"呃，那个叫单用户系统。当然，您已经消除了死锁，但您已经序列化了所有事务。
... 即使只有插入操作。显然它很罕见，但仍有可能。 这不是“罕见”。插入会在不同的点引起锁：堆；索引页；当需要移动行时。当用户数量增加时，阻塞锁和死锁就会增加。很普通。
@PerformanceDBA：“SQL 服务器将锁定”与死锁不同。对于单个可锁定资源，死锁在逻辑上是不可能的。
@PerformanceDBA：“插入会导致各个点的锁定”。没错，但它们很少导致死锁，因为插入事务（通常）涉及很少的资源和很少的资源争用。
@S.Lott：我会重申。 避免死锁的唯一方法是让整个系统使用单个表。 这是非常不正确的，SQL Server 将在表内锁定（因此阻塞，因此死锁）。在多用户系统上，您只需确保锁靠近在一起（而不是分散在许多表中），从而保证更多的阻塞锁和死锁。由于您对 SQL Server 锁定一无所知，因此我建议您 (a) 不要发布有关该主题的内容，并且 (b) 避免挑战那些知道的人。