05.11.2015 Views

Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

CHAPTER 8 ■ TRANSACTIONS 277<br />

3 Autonomous_Insert;<br />

4 rollback;<br />

5 end;<br />

6 /<br />

PL/SQL procedure successfully completed.<br />

ops$tkyte@ORA10G> select * from t;<br />

MSG<br />

-------------------------<br />

Autonomous Insert<br />

Here, only the work done by <strong>and</strong> committed in the autonomous transaction persists. The<br />

INSERT done in the anonymous block was rolled back by the rollback statement on line 4. The<br />

autonomous transaction procedure’s COMMIT has no effect on the parent transaction started in<br />

the anonymous block. In a nutshell, this captures the essence of autonomous transactions<br />

<strong>and</strong> what they do.<br />

To summarize, if you COMMIT inside a “normal” procedure, it will make durable not only<br />

its own work but also any outst<strong>and</strong>ing work performed in that session. However, a COMMIT<br />

performed in a procedure with an autonomous transaction will make durable only that<br />

procedure’s work.<br />

When to Use Autonomous Transactions<br />

The <strong>Oracle</strong> database has supported autonomous transactions internally for quite a while. We<br />

see them all of the time in the form of recursive SQL. For example, a recursive transaction may<br />

be performed when selecting from a sequence, in order for you to increment the sequence<br />

immediately in the SYS.SEQ$ table. The update of the SYS.SEQ$ table in support of your<br />

sequence was immediately committed <strong>and</strong> visible to other transactions, but your transaction<br />

was not committed as yet. Additionally, if you roll back your transaction, the increment to the<br />

sequence remained in place; it is not rolled back with your transaction, as it has already been<br />

committed. Space management, auditing, <strong>and</strong> other internal operations are performed in a<br />

similar recursive fashion.<br />

This feature has now been exposed for all to use. However, I have found that the legitimate<br />

real-world use of autonomous transactions is very limited. Time after time, I see them<br />

used as a work-around to such problems as a mutating table constraint in a trigger. This<br />

almost always leads to data integrity issues, however, since the cause of the mutating table is<br />

an attempt to read the table upon which the trigger is firing. Well, by using an autonomous<br />

transaction you can query the table, but you are querying the table now without being able to<br />

see your changes (which is what the mutating table constraint was trying to do in the first<br />

place; the table is in the middle of a modification, so query results would be inconsistent). Any<br />

decisions you make based on a query from that trigger would be questionable—you are reading<br />

“old” data at that point in time.<br />

A potentially valid use for an autonomous transaction is in custom auditing, but I stress<br />

the words “potentially valid.” There are more efficient ways to audit information in the database<br />

than via a custom written trigger. For example, you can use the DBMS_FGA package or just<br />

the AUDIT comm<strong>and</strong> itself.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!