Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

AUTONOMOUS_TRANSACTION: pros and cons

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

like image 703
ksogor Avatar asked Jun 16 '10 05:06

ksogor


People also ask

What is the advantage of Pragma autonomous transaction?

The AUTONOMOUS_TRANSACTION pragma changes the way a subprogram works within a transaction. A subprogram marked with this pragma can do SQL operations and commit or roll back those operations, without committing or rolling back the data in the main transaction.

What is Oracle autonomous transaction processing?

Autonomous Transaction Processing delivers a self-driving, self-securing, self-repairing database service that can instantly scale to meet demands of a variety of applications: mission-critical transaction processing, mixed transactions and analytics, IoT, JSON documents, and so on.

Can we use DDL statements in autonomous triggers?

Also, unlike regular triggers, autonomous triggers can execute DDL statements (such as CREATE and DROP ) using native dynamic SQL. Changes made by an autonomous transaction become visible to other transactions when the autonomous transaction commits.

What are autonomous transactions?

Autonomous Items also known as 'above the line items' – are those international transactions which happen due to profit earning motive. All profit oriented international transactions – like export and import are autonomous transactions.


1 Answers

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) 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) 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). 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). 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). 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.

like image 148
Gary Myers Avatar answered Sep 20 '22 12:09

Gary Myers