长期生活交易是否可以接受？

我想在下面的方式在2层WPF使用事务处理（或Windows窗体）应用：长期生活交易是否可以接受？

当我们打开新的形式的数据编辑，编辑和在本次交易透明持续变化，我们可以开始新的事务。然后我们可以点击“确定”按钮并提交事务，或者“取消”按钮并回滚它。如果我们想用这些数据打开另一个对话窗口，我们可以使用嵌套事务。

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

2009-12-28 Alex Kofman

这里，如果你走这条路

连接时可能遇到的重置/关闭/ 超时（如果用户去卫生间）
数据库配置（数据库有几个问题主要是为很多短交易预先配置，而不是长期交易，例如跟踪tx期间所做的操作的撤消日志可能需要调整）
锁问题，甚至mayb e交易死锁（交易时间越长，相同锁定获得两次的可能性就越大）。

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

来源

2009-12-28 10:53:07 ewernli

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

我会尽量避免。

正如其他人所指出的，在等待用户输入时，您不应该保持事务处于打开状态。

来源

2009-12-28 07:45:38

请问downvoter请留言。谢谢。 – 2009-12-28 13:28:56

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

您需要重新考虑您的方法。为什么你会在用户填写表单时打开交易？我们使用事务来管理并发和锁定共享资源。填写表格并不具备真正的资格。

来源

2009-12-28 08:10:12 Cheeso

我同意Mitch n Cheeso，但仍然有一种将Timeout放在窗口上的方法，您可以通知一个时钟，如果用户没有按下“OK”，那么窗口会自动关闭，一切都会取消。

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

来源

2009-12-28 08:37:03

关于可用性：如果有东西被保留（例如一张票）并且必须在超时后被释放，那么窗口上的时钟是可以接受的。即使这样，不要关闭它（用户不知道发生了什么），只要发出一条消息并给用户一个按钮，以便在可能的情况下重新保留。但如果你不在这样一个系统中工作，乐观锁定策略要好得多。让用户随时需要，并且除非实际存在问题，否则不要取消表格。 – benzado 2010-01-05 20:28:18

我同意，给予altert重新打开窗口是附加功能，这是UI插件，但关闭是必要的，因为如果用户离开一些其他任务，或网络卡住，数据库将不必要的锁定和其他一些用户可能会遭受，所以它对于在预订系统中关闭交易非常重要。 – 2010-01-06 10:50:03

长期生活交易是学术界围绕...... 20世纪80年代热点讨论的话题。问题在于，长期存在的交易几乎肯定会导致悲观执行中的僵局，并且几乎肯定需要在乐观执行中解决复杂的冲突解决方案（对于数字，您可以参考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。例如，“长交易”可能不得不公开其中间结果，这违反了隔离属性。但是没有任何一个提案对于这个行业颇具影响力，可以这么说。主要是因为这些技术不是真的......简化，也没有必要解决实际的业务问题。

因此，要回答您的问题：不，在主流数据库引擎中不欢迎长期生活的交易。

来源

2009-12-28 12:12:18

长期生活交易是否可以接受？

回答

相关问题