AUTONOMOUS_TRANSACTION:利弊 [英] AUTONOMOUS_TRANSACTION: pros and cons

查看:62
本文介绍了AUTONOMOUS_TRANSACTION:利弊的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

自主交易会危险吗?如果是,在什么情况下?什么时候需要自主交易?

Can be autonomous transactions dangerous? If yes, in which situations? When autonomous transactions are necessary?

推荐答案

是的,自主交易可能很危险.

Yes, autonomous transactions can be dangerous.

考虑主要交易的情况.它已插入/更新/删除了行.如果您随后在其中设置了自主交易,则可以

Consider the situation where you have your main transaction. It has inserted/updated/deleted rows. If you then, within that, set up an autonomous transaction then either

(1)它将完全不查询任何数据.这是安全"的情况.独立于主事务记录日志可能很有用,这样就可以在不影响主事务的情况下进行提交(当您希望主事务回滚时,这对于记录错误信息很有用).

(1) It will not query any data at all. This is the 'safe' situation. It can be useful to log information independently of the primary transaction so that it can be committed without impacting the primary transaction (which can be useful for logging error information when you expect the primary transaction to be rolled back).

(2)仅查询尚未由主事务更新的数据.这是安全的,但是是多余的.没有必要进行自主交易.

(2) It will only query data that has not been updated by the primary transaction. This is safe, but superfluous. There is no point to the autonomous transaction.

(3).它将查询已由主事务更新的数据.由于您已经覆盖了某些内容,因此在重写之前需要回头看看它是什么,这使您在设计时缺乏思想.有时,人们认为自主事务仍然会看到主要事务的未提交更改,而不会.它读取数据库的当前提交状态,以及在自主事务中进行的任何更改.有些人(通常是为了响应变化的触发错误而尝试进行自动交易)在尝试读取数据时并不关心数据处于什么状态,因此根本不应该允许这些人访问数据库.

(3). It will query data that has been updated by the primary transaction. This smacks of a poorly thought through design, since you've overwritten something and then need to go back to see what it was before you overwrote it. Sometimes people think that an autonomous transaction will still see the uncommitted changes of the primary transaction, and it won't. It reads the currently committed state of the database, plus any changes made within the autonomous transaction. Some people (often trying autonomous transactions in response to mutating trigger errors) don't care what state the data is in when they try to read it and these people simply shouldn't be allowed access to a database.

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

(4). It will try to update/delete data that hasn't been updated by the primary transaction. Again, this smacks of poor design. These changes are going to get committed (or rolled back) whether or not the primary transaction succeeds or fails. Worse you risk issue (5) since it is hard to determine, within an autonomous transaction, whether the data has been updated by the primary transaction.

(5).您尝试更新/删除已由主事务更新的数据,在这种情况下,它将死锁并最终导致混乱.

(5). You try to update/delete data that has already been updated by the primary transaction, in which case it will deadlock and end up in an ugly mess.

这篇关于AUTONOMOUS_TRANSACTION:利弊的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆