You are on page 1of 4

AUTONOMOUS_TRANSACTION Pragma:

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.

Autonomous Transactions provide a new method of controlling transactions in stored


procedures. Autonomous Transactions allow you to create a new subtransaction that may
commit or rollback changes independent of the parent transaction.

Syntax

pragma autonomous_transaction ::=

PRAGMA

Signifies that the statement is a pragma (compiler directive). Pragmas are processed at
compile time, not at run time. They pass information to the compiler.

Usage Notes :

You can apply this pragma to:

• Top-level (not nested) anonymous PL/SQL blocks


• Local, standalone, and packaged functions and procedures
• Methods of a SQL object type
• Database triggers

You cannot apply this pragma to an entire package or an entire an object type. Instead,
you can apply the pragma to each packaged subprogram or object method.

You can code the pragma anywhere in the declarative section. For readability, code the
pragma at the top of the section.

Once started, an autonomous transaction is fully independent. It shares no locks,


resources, or commit-dependencies with the main transaction. You can log events,
increment retry counters, and so on, even if the main transaction rolls back.

Unlike regular triggers, autonomous triggers can contain transaction control statements
such as COMMIT and ROLLBACK, and can issue DDL statements (such as CREATE
and DROP) through the EXECUTE IMMEDIATE statement.
Changes made by an autonomous transaction become visible to other transactions when
the autonomous transaction commits. The changes also become visible to the main
transaction when it resumes, but only if its isolation level is set to READ COMMITTED
(the default). If you set the isolation level of the main transaction to SERIALIZABLE,
changes made by its autonomous transactions are not visible to the main transaction when
it resumes.

In the main transaction, rolling back to a savepoint located before the call to the
autonomous subprogram does not roll back the autonomous transaction. Remember,
autonomous transactions are fully independent of the main transaction.

If an autonomous transaction attempts to access a resource held by the main transaction


(which cannot resume until the autonomous routine exits), a deadlock can occur. Oracle
raises an exception in the autonomous transaction, which is rolled back if the exception
goes unhandled.

If you try to exit an active autonomous transaction without committing or rolling back,
Oracle raises an exception. If the exception goes unhandled, or if the transaction ends
because of some other unhandled exception, the transaction is rolled back.

Pros and Cons of Autonomous Transactions:


There are not many drawbacks that come to mind with autonomous transactions. Once
you understand how they work and what they are useful for, they work without any
‘gotchas’. They have very few limitations or restrictions and, as they have been
implemented for a long time in Oracle as recursive SQL, they are very well tested.

Pros Cons

Allows you to commit in a trigger Cannot perform parallel queries in


autonomous transactions. These queries will
execute serially.

Allows you to perform DML from a Deadlocks may occur more frequently as a
SELECT single user can now deadlock themselves

Allows for more modular code with less Must be used in a top level anonymous
side effects (avoids the "hey – you rolled block, procedure, or function. Cannot be
back my work!") included in a nested PL/SQL block.

Allows you to implement auditing that


cannot be rolled back
As it is an extension of recursive SQL, it is
a feature that has been around internally for
a long time (tested).

EXAMPLES:

1) Declaring an Autonomous Function in a Package

CREATE OR REPLACE PACKAGE emp_actions AS -- package


specification
FUNCTION raise_salary (emp_id NUMBER, sal_raise NUMBER)
RETURN NUMBER;
END emp_actions;
/
CREATE OR REPLACE PACKAGE BODY emp_actions AS -- package
body
-- code for function raise_salary
FUNCTION raise_salary (emp_id NUMBER, sal_raise NUMBER)
RETURN NUMBER IS
PRAGMA AUTONOMOUS_TRANSACTION;
new_sal NUMBER(8,2);
BEGIN
UPDATE employees SET salary = salary + sal_raise WHERE
employee_id = emp_id;
COMMIT;
SELECT salary INTO new_sal FROM employees WHERE
employee_id = emp_id;
RETURN new_sal;
END raise_salary;
END emp_actions;
/

2) Declaring an Autonomous Standalone Procedure

CREATE PROCEDURE lower_salary (emp_id NUMBER, amount


NUMBER) AS
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
UPDATE employees SET salary = salary - amount WHERE
employee_id = emp_id;
COMMIT;
END lower_salary;
/
3) Declaring an Autonomous PL/SQL Block

DECLARE
PRAGMA AUTONOMOUS_TRANSACTION;
emp_id NUMBER(6);
amount NUMBER(6,2);
BEGIN
emp_id := 200;
amount := 200;
UPDATE employees SET salary = salary - amount WHERE
employee_id = emp_id;
COMMIT;
END;
/

You might also like