长期交易是否可以接受？ [英] Are long-living transactions acceptable?

问题描述

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

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

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

解决方案

• 连接重置/关闭/ 超时
  / strong>（如果用户转到浴室）


• 数据库配置（数据库主要是为许多短交易预配置的，记录在tx期间所做的事情可能需要调整）


• 锁定问题，甚至可能是死锁（事务时间越长）

这是一个不鼓励的练习。请改用乐观锁定。必要时读取数据，将副本保存在内存中。当对话框关闭时，尝试将更改与数据库同步。如果在数据库中间修改了数据，则操作将中止。其失败的概率将取决于用户的数字等。但这在实践中经常是可接受的。

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.

解决方案

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.

这篇关于长期交易是否可以接受？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！