长期交易是否可以接受？

Question

我正在考虑以下列方式在2层WPF（或Windows窗体）应用程序中使用事务：

当我们打开新表格来编辑数据，在此交易中透明地编辑和保持更改时，我们可以开始新的交易。然后我们可以单击“确定”按钮并提交事务，或“取消”按钮并回滚它。如果我们想要打开另一个包含此数据的对话框窗口，我们可以使用嵌套事务。

问题是：这种使用交易的方式是否可以接受？我知道有很多不同的方法来实现这样的逻辑，但我想列出这个逻辑的优点和缺点。

Answer 1

长期生活交易是学术界热议的话题...... 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。例如，“长事务”可能必须公开其中间结果，这违反了隔离属性。但是，所有提案都没有提到业界。主要是因为这些技术并非真正......简化，也没有必要解决实际的业务问题。

所以，回答你的问题：不，主流数据库引擎不欢迎长期交易。

Answer 2

如果你这样做，可能会遇到一些问题

• 连接重置/关闭/ 超时（如果用户进入浴室）
• 数据库配置（数据库大部分是针对许多短交易预先配置的，而不是长交换。例如，跟踪tx期间已执行的操作的撤消日志可能需要调整）< / LI>
• 锁定问题，甚至可能是死锁（事务处理时间越长，相同锁定的可能性就越大，可能会以冲突的顺序获得两次）

这是一种沮丧的做法。请改用乐观锁定。必要时读取数据，在内存中保留一份副本。关闭对话框时，尝试将更改与数据库同步。如果数据库之间的数据已被修改，则操作将中止。它失败的可能性取决于用户的数量等。但这在实践中经常被接受。

Answer 3

长时间运行的交易会严重影响您的扩展能力。

如果可能，我会尽量避免。

正如其他人所说，你不应该在等待用户输入时保持交易开放。

Answer 4

不，在等待用户输入时不要保持事务处于打开状态。这是糟糕的设计，会导致事务资源（数据库）出现锁定问题。

您需要重新考虑您的方法。当用户填写表单时，为什么要打开事务？我们使用事务来管理并发和锁定共享资源。填写表格并不符合要求。

Answer 5

我同意Mitch n Cheeso，但还有另外一种方法可以将Timeout放在窗口上，你可以通知一个时钟，如果用户没有按“OK”，那么窗口将自动关闭，一切都将被取消

大多数交易都很重要的系统，如航空公司，电影等的“预订”流程，运营商应该在有限的时间内完成交易。