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 275<br />

Autonomous Transactions<br />

Autonomous transactions allow you to create a “transaction within a transaction” that will<br />

commit or roll back changes independently of its parent transaction. They allow you to suspend<br />

the currently executing transaction, start a new one, do some work, <strong>and</strong> commit or roll<br />

back—all without affecting the currently executing transaction state. Autonomous transactions<br />

provide a new method of controlling transactions in PL/SQL <strong>and</strong> may be used in<br />

• Top-level anonymous blocks<br />

• Local (a procedure in a procedure), st<strong>and</strong>-alone, or packaged functions <strong>and</strong> procedures<br />

• Methods of object types<br />

• <strong>Database</strong> triggers<br />

Before we take a look at how autonomous transactions work, I would like to emphasize<br />

that they are a powerful <strong>and</strong> therefore dangerous tool when used improperly. The true need<br />

for an autonomous transaction is very rare indeed. I would be very suspicious of any code that<br />

makes use of them—that code would get an extra looking at. It is far too easy to accidentally<br />

introduce logical data integrity issues into a system using them. In the sections that follow,<br />

we’ll discuss when they may safely be used after seeing how they work.<br />

How Autonomous Transactions Work<br />

The best way to demonstrate the actions <strong>and</strong> consequences of an autonomous transaction is<br />

by example. We’ll create a simple table to hold a message:<br />

ops$tkyte@ORA10G> create table t ( msg varchar2(25) );<br />

Table created.<br />

Next, we’ll create two procedures, each of which simply INSERTs its name into the message<br />

table <strong>and</strong> commits. However, one of these procedures is a normal procedure <strong>and</strong> the<br />

other is coded as an autonomous transaction. We’ll use these objects to show what work persists<br />

(is committed) in the database under various circumstances.<br />

First, here’s the AUTONOMOUS_INSERT procedure:<br />

ops$tkyte@ORA10G> create or replace procedure Autonomous_Insert<br />

2 as<br />

3 pragma autonomous_transaction;<br />

4 begin<br />

5 insert into t values ( 'Autonomous Insert' );<br />

6 commit;<br />

7 end;<br />

8 /<br />

Procedure created.<br />

Note the use of the pragma AUTONOMOUS_TRANSACTION. That directive tells the database that<br />

this procedure, when executed, is to be executed as a new autonomous transaction, independent<br />

from its parent transaction.

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

Saved successfully!

Ooh no, something went wrong!