我正在考虑通过以下方式在 2 层 WPF（或 Windows 窗体）应用程序中使用事务：
当我们打开新表单来编辑数据时，我们可以开始新的事务，在这个事务中透明地编辑和持久化更改。然后我们可以单击“确定”按钮并提交事务，或单击“取消”按钮并回滚它。如果我们想用这些数据打开另一个对话窗口，我们可以使用嵌套事务。
问题是：这种使用交易的方式是否可以接受？我知道实现这种逻辑有很多不同的方法，但我想列出这种方法的优缺点。
【问题讨论】：
标签： database language-agnostic transactions data-access-layer
长期交易是学术界讨论的热门话题……我想说的是 1980 年代。问题是，长期事务几乎肯定会在悲观执行中产生死锁，并且几乎肯定需要在乐观执行中解决复杂的冲突（有关数字，您可以咨询Jim Gray's paper "The Dangers of Replication and a Solution"，但随着事务的五次方，死锁很快就会上升大小，并且发生碰撞的概率随着二次方的增加而增加）。
现在对于这个问题有不同的建议，比如来自 Salem 和 Garcia-Molina 的"sagas"，“嵌套交易”等等（another Jim Gray's paper "The Transaction Concept: Virtues and Limitations" 最后有几页关于这个问题）。大多数提案都处理交易模型，比 ACID 弱。例如，“长事务”可能必须公开它们的中间结果，这违反了 Isolation 属性。但可以这么说，这些提议都没有真正进入业界。主要是因为这些技术并没有真正......简化，也不是解决实际业务问题所必需的。
所以，回答您的问题：不，主流数据库引擎不欢迎长期事务。
【讨论】：
如果你这样做，你可能会遇到一些问题
这是一种不鼓励的做法。请改用乐观锁定。必要时读取数据，在内存中保留一份副本。当对话框关闭时，尝试将更改与数据库同步。如果在两者之间修改了数据库中的数据，则中止操作。它失败的概率取决于用户数量等。但这在实践中通常是可以接受的。
【讨论】：
长时间运行的事务会严重影响您的扩展能力。
如果可能的话，我会避免。
正如其他人所指出的，您不应该在等待用户输入时保持交易处于打开状态。
【讨论】：
不，在等待用户输入时不要保持交易打开。这是一个糟糕的设计，会导致事务资源（数据库）出现锁定问题。
您需要重新考虑您的方法。为什么在用户填写表格时打开交易？我们使用事务来管理共享资源的并发和锁定。填写表格并不真正符合条件。
【讨论】：
我同意 Mitch n Cheeso 的观点，但还有另一种方法可以在窗口上设置 Timeout，您可以通知时钟，如果用户不按“OK”，则窗口将自动关闭，一切都将被取消.
大多数对交易至关重要的系统，如航空公司、电影等的“预订”流程，运营商应该在有限的时间内完成交易。
【讨论】：