AUTONOMOUS_TRANSACTION:利弊得失

Question

自主交易会有危险吗？如果是，在什么情况下？什么时候需要自主事务？

Answer 1

是的，自主事务可能是危险的。

考虑一下您拥有主事务的情况。它有插入/更新/删除的行。如果您随后在其中设置了一个自治事务，则可以

(1)不会查询任何数据。这是“安全”的情况。独立于主事务记录信息可能很有用，这样就可以在不影响主事务的情况下提交信息(当您期望回滚主事务时，这对于记录错误信息很有用)。

(2)只查询未被主交易更新的数据。这是安全的，但也是多余的。自主事务是没有意义的。

(3)。它将查询已由主事务更新的数据。这有点糟糕的设计思想，因为你已经覆盖了一些东西，然后需要在覆盖它之前回去看看它是什么。有时人们认为自治事务仍然会看到主事务的未提交更改，但它不会。它读取数据库的当前提交状态，以及在自治事务中所做的任何更改。有些人(经常尝试自主事务以响应不断变化的触发器错误)并不关心他们试图读取数据时数据处于什么状态，这些人根本不应该被允许访问数据库。

(4)。它将尝试更新/删除尚未由主事务更新的数据。再说一次，这有点糟糕的设计。无论主事务成功还是失败，这些更改都将被提交(或回滚)。更糟糕的是，您将面临问题(5)，因为在自治事务中，很难确定主事务是否更新了数据。

(5)。您尝试更新/删除已经由主事务更新的数据，在这种情况下，它将死锁并以一片混乱而告终。

Answer 2

可能是自治交易的危险吗？

是。

如果是，在什么情况下？

当他们被滥用的时候。例如，当用于在回滚父事务的其余部分时对本应回滚的数据进行更改时。滥用它们可能会导致数据损坏，因为更改的某些部分已提交，而其他部分未提交。

何时需要自主事务？

当一个事务的影响必须保留时，无论父事务是提交还是回滚，它们都是必需的。一个很好的例子是将进程的进度和活动记录到数据库表中的过程。

Answer 3

何时需要自主事务？

检查我的问题：How can LOCK survive COMMIT or how can changes to LOCKed table be propagated to another session without COMMIT and losing LOCK

我们按顺序接收业务配置，并应禁止并行处理。

我使用锁对表进行配置，并相应地更新其他表。我将每个批量更新提交到其他表，因为我们负担不起在所有记录上保持事务-冲突的概率将接近0.99。

由于并发访问而导致的每一次失败都会被保存到日志中，以便以后进行更新尝试。