我的应用程序将一些数据存储在名为事务的 SQL 表中。用户可以将 Client1 的东西卖给 Client2，然后 Client2 拥有它。我通过以下方式将其存储在表中:
Client 1 | Buy | Something | Price | External |
Client 1 | Sell | Something | Price2 | Client 2 |
Client 2 | Buy | Something | Price2 | Client 1 |
第一个客户 1 购买了它(将其带入或只是拥有它而已)。然后他把它卖给另一个客户。
一切都很好，它可以工作，但我的应用程序有很短的时间不检查客户端 1 是否仍然拥有它声称拥有的东西(当数据加载到 gui 时)。 因此，如果有 2 个用户参与其中，则 Client1 的产品可能会被多次销售。这很可能不会发生，因为我的用户倾向于分享他们正在做的事情的工作，但总是有但是......
如何预防？在插入事务之前进行简单的选择查询检查是否足够，还是应该以不同的方式进行？ (我可以想象当多人为之奔跑并且有些人会成功的情况)。这在重型系统的现实情况下是如何处理的？就像当您使用来自 2 台不同 CashMachines 的 2 张卡从一个银行账户取钱时(尽管我相信在这种情况下他们只会让余额低于 0，即使不允许)。
那么我有什么选择呢？您对此有何看法？
最佳答案
我假设这不是一个真正的库存跟踪系统，其中数据库仅记录现实世界的事件，而是某种虚拟拍卖或市场类型的应用程序，其中“现实”是应用程序认为的任何东西。
如果你只保留历史，你永远不会有当前状态。没有当前状态，您无法做出有效的正确性决策。所以保持当前状态。有一个项目表及其当前所有者。然后你问的问题就变成了一个简单的问题“如何防止更新丢失？”或“如何防止盲写”？ (即 write-write 冲突)并且答案在数据库应用程序中众所周知:使用 optimistic concurrency控制。
有关如何将乐观并发与 C# 和 SQL 结合使用的详细讨论，请参阅 Optimistic Concurrency (ADO.NET) .
关于c# - 如何解决销售数据库中的并发事务问题，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2396997/