长期交易是否可以接受？

Question

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

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

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

Answer 1

长期生活交易是学术界热议的话题...... 1980年代我会说.问题在于,长期存在的事务几乎肯定会在悲观执行中造成死锁,并且几乎肯定需要在乐观执行中解决复杂的冲突(对于数字,您可以参考Jim Gray的论文"复制的危险和解决方案",但不久死锁作为交易规模的五次幂上升,并且碰撞的概率随着第二次幂而上升.

现在对这个问题提出了不同的建议,例如Salem和Garcia-Molina的"sagas","嵌套交易"等等(另一个Jim Gray的论文"交易概念:美德与限制"最后有几页关于这一点) .大多数提案涉及交易模型,弱于ACID.例如,"长事务"可能必须公开其中间结果,这违反了隔离属性.但是,所有提案都没有提到业界.主要是因为这些技术并非真正......简化,也没有必要解决实际的业务问题.

所以,回答你的问题:不,主流数据库引擎不欢迎长期交易.

Answer 2

如果你走这条路,可能会遇到一些问题

• 连接重置/关闭/ 超时(如果用户进入浴室)
• 数据库配置(数据库大多是为许多短事务预先配置的,而不是长事务.例如,跟踪tx期间所做的事情的撤销日志可能需要调整)
• 锁定问题,甚至可能是死锁(交易时间越长,相同锁定的可能性就越大,可能是冲突的顺序)

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