Using Serializable Transactions for Concurrency Control

Viewing and Monitoring Locks

Table 5–4 describes Oracle Database facilities to display locking information for ongoing transactions within an instance.

Table 5–2 Ways to Display Locking Information

Using Serializable Transactions for Concurrency Control

By default, Oracle Database permits concurrently executing transactions to modify, add, or delete rows in the same table, and in the same data block. Changes made by one transaction are not seen by another concurrent transaction until the transaction that made the changes commits.

If a transaction A attempts to update or delete a row that has been locked by another transaction B (by way of a DML or SELECT... FOR UPDATE statement), then A's DML command blocks until B commits or rolls back. Once B commits, transaction A can see changes that B has made to the database.

For most applications, this concurrency model is the appropriate one, because it provides higher concurrency and thus better performance. But some rare cases require transactions to be serializable. Serializable transactions must execute in such a way that they appear to be executing one at a time (serially), rather than concurrently. Concurrent transactions executing in serialized mode can only make

How Oracle Database Processes SQL Statements 5-19

Using Serializable Transactions for Concurrency Control

database changes that they could have made if the transactions ran one after the other.

Figure 5–2 shows a serializable transaction (B) interacting with another transaction

(A).

The ANSI/ISO SQL standard SQL92 defines three possible kinds of transaction interaction, and four levels of isolation that provide increasing protection against these interactions. These interactions and isolation levels are summarized in Table 5–3.

Table 5–3 Summary of ANSI Isolation Levels

1A transaction can read uncommitted data changed by another transaction.

2A transaction rereads data committed by another transaction and sees the new data.

3A transaction can execute a query again, and discover new rows inserted by another committed transaction.

The behavior of Oracle Database with respect to these isolation levels is summarized in Table 5–4.

Table 5–4 ANSI Isolation Levels and Oracle Database

READ UNCOMMITTED Oracle Database never permits "dirty reads." Although some other database products use this undesirable technique to improve thoughput, it is not required for high throughput with Oracle Database.

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

How Serializable Transactions Interact

Figure 5–2 on page 5-22 shows how a serializable transaction (Transaction B) interacts with another transaction (A, which can be either SERIALIZABLE or READ COMMITTED).

When a serializable transaction fails with an ORA-08177 error ("cannot serialize access"), the application can take any of several actions:

■Commit the work executed to that point

■Execute additional, different, statements, perhaps after rolling back to a prior savepoint in the transaction

■Roll back the entire transaction and try it again

Oracle Database stores control information in each data block to manage access by concurrent transactions. To use the SERIALIZABLE isolation level, you must use the INITRANS clause of the CREATE TABLE or ALTER TABLE command to set aside storage for this control information. To use serializable mode, INITRANS must be set to at least 3.

How Oracle Database Processes SQL Statements 5-21

Using Serializable Transactions for Concurrency Control

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