可以自主交易危险吗？如果是，在哪些情况下？什么时候需要自主交易？
答案 0 :(得分：17)
是的，自主交易可能很危险。
考虑您拥有主要交易的情况。它已插入/更新/删除了行。如果你那么，在那之内，设置一个自治交易然后
（1）它根本不会查询任何数据。这是'安全'的情况。独立于主事务记录信息非常有用，这样可以在不影响主事务的情况下提交信息（当您希望回滚主事务时，这对于记录错误信息非常有用）。
（2）它只会查询主要事务尚未更新的数据。这是安全的，但是多余的。自治交易毫无意义。
（3）。它将查询主事务已更新的数据。由于你已经覆盖了某些东西，然后需要在覆盖它之前回去查看它是什么，这就是设计思路很差。有时人们认为自主交易仍然会看到主要交易的未提交变更，但事实并非如此。它读取当前已提交的数据库状态，以及在自治事务中进行的任何更改。有些人（通常尝试自动交易以应对突变的触发错误）并不关心数据在尝试读取时的状态，并且不应允许这些人访问数据库。
（4）。它将尝试更新/删除主要事务尚未更新的数据。再次，这是糟糕的设计。无论主要事务是成功还是失败，这些更改都将被提交（或回滚）。更糟糕的是风险问题（5），因为在自主交易中很难确定数据是否已被主要交易更新。
（5）。您尝试更新/删除主要事务已更新的数据，在这种情况下，它将陷入僵局并最终陷入困境。
答案 1 :(得分：11)
可以自主交易危险吗？
是
如果是，在哪些情况下？
当他们被滥用时。例如，当用于对数据进行更改时，如果回滚父事务的其余部分，则应该回滚这些数据。滥用它们会导致数据损坏，因为更改的某些部分已提交，而其他部分则未提交。
什么时候需要自主交易？
当一个事务的影响必须存在时，无论父事务是提交还是回滚，它们都是必需的。一个很好的例子是将进程的进度和活动记录到数据库表的过程。
答案 2 :(得分：0)
何时需要进行自主交易？
我们按顺序提取业务配置，并且应禁止并行处理。
我使用锁来配置表，并相应地更新其他表。我将每个批处理的更新提交给其他表，因为我们不能负担所有记录的事务-发生冲突的可能性接近0.99。
由于并发访问而导致的每个失败都将持续记录下来，以供以后尝试更新。