Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Скачиваний:
32
Добавлен:
16.04.2013
Размер:
4.96 Mб
Скачать

Autonomous Transactions

READ COMMITTED isolation can provide considerably more concurrency with a somewhat increased risk of inconsistent results (due to phantoms and non-repeatable reads) for some transactions. The SERIALIZABLE isolation level provides somewhat more consistency by protecting against phantoms and non-repeatable reads, and may be important where a read/write transaction executes a query more than once. However, SERIALIZABLE mode requires applications to check for the "can't serialize access" error, and can significantly reduce throughput in an environment with many concurrent transactions accessing the same data for update. Application logic that checks database consistency must take into account the fact that reads do not block writes in either mode.

Application Tips for Transactions

When a transaction runs in serializable mode, any attempt to change data that was changed by another transaction since the beginning of the serializable transaction causes an error:

ORA-08177: Can't serialize access for this transaction.

When you get this error, roll back the current transaction and execute it again. The transaction gets a new transaction snapshot, and the operation is likely to succeed.

To minimize the performance overhead of rolling back transactions and executing them again, try to put DML statements that might conflict with other concurrent transactions near the beginning of your transaction.

Autonomous Transactions

This section gives a brief overview of autonomous transactions and what you can do with them.

See Also: PL/SQL User's Guide and Reference and Chapter 9, "Using Triggers" for detailed information on autonomous transactions

At times, you may want to commit or roll back some changes to a table independently of a primary transaction's final outcome. For example, in a stock purchase transaction, you may want to commit a customer's information regardless of whether the overall stock purchase actually goes through. Or, while running that same transaction, you may want to log error messages to a debug table even if the overall transaction rolls back. Autonomous transactions allow you to do such tasks.

5-28 Oracle Database Application Developer's Guide - Fundamentals

Autonomous Transactions

An autonomous transaction (AT) is an independent transaction started by another transaction, the main transaction (MT). It lets you suspend the main transaction, do SQL operations, commit or roll back those operations, then resume the main transaction.

An autonomous transaction executes within an autonomous scope. An autonomous scope is a routine you mark with the pragma (compiler directive) AUTONOMOUS_ TRANSACTION. The pragma instructs the PL/SQL compiler to mark a routine as autonomous (independent). In this context, the term routine includes:

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

Local, standalone, and packaged functions and procedures

Methods of a SQL object type

PL/SQL triggers

Figure 5–4 shows how control flows from the main routine (MT) to an autonomous routine (AT) and back again. As you can see, the autonomous routine can commit more than one transaction (AT1 and AT2) before control returns to the main routine.

Figure 5–4 Transaction Control Flow

 

 

 

 

 

 

 

 

 

 

Main Routine

 

 

 

 

Autonomous Routine

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

PROCEDURE proc1 IS

 

 

 

 

PROCEDURE proc2 IS

 

 

 

 

emp_id NUMBER;

 

 

 

 

PRAGMA AUTON...

 

 

 

 

BEGIN

 

 

 

 

dept_id NUMBER;

 

 

 

 

emp_id := 7788;

 

 

 

 

BEGIN

 

 

 

 

 

 

MT suspends

 

 

 

 

 

 

 

 

 

 

 

INSERT ...

 

 

 

MT begins

dept_id := 20;

 

 

 

 

 

 

 

 

 

 

SELECT ...

 

 

 

 

UPDATE ...

 

 

 

AT1 begins

 

 

 

 

 

 

 

 

proc2;

 

 

 

 

 

INSERT ...

 

 

 

 

 

 

 

 

 

 

 

 

 

DELETE ...

 

 

 

 

UPDATE ...

 

 

 

 

COMMIT;

 

 

 

MT ends

COMMIT;

 

 

 

 

 

AT1 ends

 

 

 

 

 

 

 

 

 

 

END;

 

 

 

 

INSERT ...

 

 

 

AT2 begins

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

INSERT ...

 

 

AT2 ends

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

COMMIT;

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

END;

 

 

 

 

 

MT resumes

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

When you enter the executable section of an autonomous routine, the main routine suspends. When you exit the routine, the main routine resumes. COMMIT and ROLLBACK end the active autonomous transaction but do not exit the autonomous routine. As Figure 5–4 shows, when one transaction ends, the next SQL statement begins another transaction.

How Oracle Database Processes SQL Statements 5-29

Autonomous Transactions

A few more characteristics of autonomous transactions:

The changes autonomous transactions effect do not depend on the state or the eventual disposition of the main transaction. For example:

An autonomous transaction does not see any changes made by the main transaction.

When an autonomous transaction commits or rolls back, it does not affect the outcome of the main transaction.

The changes an autonomous transaction effects are visible to other transactions as soon as that autonomous transaction commits. This means that users can access the updated information without having to wait for the main transaction to commit.

Autonomous transactions can start other autonomous transactions.

Figure 5–5 illustrates some of the possible sequences autonomous transactions can follow.

5-30 Oracle Database Application Developer's Guide - Fundamentals

Autonomous Transactions

Figure 5–5 Possible Sequences of Autonomous Transactions

A main transaction scope (MT Scope) begins the main transaction, MTx. MTx invokes the first autonomous transaction scope (AT Scope1). MTx suspends. AT Scope 1 begins the transaction Tx1.1.

At Scope 1 commits or rolls back Tx1.1, than ends. MTx resumes.

MTx invokes AT Scope 2. MT suspends, passing control to AT Scope 2 which, initially, is performing queries.

AT Scope 2 then begins Tx2.1 by, say, doing an update. AT Scope 2 commits or rolls back Tx2.1.

Later, AT Scope 2 begins a second transaction, Tx2.2, then commits or rolls it back.

AT Scope 2 performs a few queries, then ends, passing control back to MTx.

MTx invokes AT Scope 3. MTx suspends, AT Scope 3 begins.

AT Scope 3 begins Tx3.1 which, in turn, invokes AT Scope 4. Tx3.1 suspends, AT Scope 4 begins.

AT Scope 4 begins Tx4.1, commits or rolls it back, then ends. AT Scope 3 resumes.

AT Scope 3 commits or rolls back Tx3.1, then ends. MTx resumes.

Finally, MT Scope commits or rolls back MTx, then ends.

MT Scope

 

 

AT Scope 1

 

 

AT Scope 2

 

 

AT Scope 3

 

 

AT Scope 4

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

MTx

Tx1.1

MTx

Tx2.1

Tx2.2

MTx

Tx3.1

Tx4.1

Tx3.1

MTx

How Oracle Database Processes SQL Statements 5-31

Тут вы можете оставить комментарий к выбранному абзацу или сообщить об ошибке.

Оставленные комментарии видны всем.

Соседние файлы в папке Oracle 10g