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

长期生活交易是否可以接受？(Are long-living transactions acceptable?)

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

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

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

I am thinking about using transactions in 2-tier WPF (or windows forms) applications in following way:

We can begin new transaction when we open new form for editing data, edit and persist changes transparently in this transaction. Then we can click "OK" button and commit transaction, or "Cancel" button and rollback it. If we want to open another dialog window with this data, we can use nested transactions.

The question is: Is this way of using transactions acceptable or not? I know that there are a lot of different ways to implement such logic, but I'd like to list advantages and disadvantages of this one.

最满意答案

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

连接重置/关闭/ 超时 （如果用户去洗手间） 数据库配置 （数据库大部分是针对很多短事务进行预配置的，而不是长事务，例如，可能需要调整跟踪tx期间完成的事务的撤消日志） 锁问题，甚至可能是死锁（交易时间越长，相同的锁可能以相互冲突的顺序获得两次的可能性越大）

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

Here is a few problem that you might encounter if you go this way

connection reset/close/timeout (if user goes to the bathroom) database configuration (database are mostly pre-configured for many short transactions, not long ones. E.g. the undo log that keeps track of what has been done during the tx may need to be tuned) lock issues, even maybe deadlocks (the longer the transactions are, bigger the chances are the same lock is acquired twice possibly in conflicting order)

This is a discouraged practice. Use optimistic locking instead. Read data when necessary, keep a copy in memory. When dialog is closed, attempt to synchronize the changes with the database. If data have been modified in the database in between, the action is aborted. The probability that it fails will depend on the numer of users, etc. But this is frequently acceptable in practice.