A lock is a mechanism that prevents destructive interactions, which are interactions that incorrectly update data or incorrectly alter underlying data structures, between transactions accessing shared data. Locks play a crucial row in maintaining database concurrency and consistency.
Locking Behavior
The database maintains several different types of locks, depending on the operation that acquired the lock. In general, the
database uses two types of locks: exclusive locks and share locks. Only one exclusive lock can be obtained on a resource such as a row or a table, but many share locks can be obtained on a single resource.
Locks affect the interaction of readers and writers. A reader is a query of a resource, whereas a writer is a statement modifying a resource. The following rules summarize the locking
behavior of Oracle Database for readers and writers:
■A row is locked only when modified by a writer.
When a statement updates one row, the transaction acquires a lock for this row only. By locking table data at the row level, the database minimizes contention for the same data. Under
normal circumstances1 the database does not escalate a row lock to the block or table level.
■A writer of a row blocks a concurrent writer of the same row.
If one transaction is modifying a row, then a row lock prevents a different transaction from modifying the same row simultaneously.
■A reader never blocks a writer.
Because a reader of a row does not lock it, a writer can modify this row. The only exception is a SELECT ... FOR UPDATE statement, which is a special type of SELECT statement that does
lock the row that it is reading.
■A writer never blocks a reader.
When a row is being changed by a writer, the database uses undo data data to provide readers with a consistent view of the row.
Use of Locks
In a single-user database, locks are not necessary because only one user is modifying information. However, when multiple
users are accessing and modifying data, the database must provide a way to prevent concurrent modification of the same data. Locks achieve the following important database requirements:
■Consistency
The data a session is viewing or changing must not be changed by other sessions until the user is finished.
■Integrity
The data and structures must reflect all changes made to them in the correct sequence.
Oracle Database provides data concurrency, consistency, and integrity among transactions through its locking mechanisms.
Locking is performed automatically and requires no user action.
The need for locks can be illustrated by a concurrent update of a single row. In the following example, a simple web-based application presents the end user with an employee email and
phone number. The application uses an UPDATE statement such as the following to modify the data:
UPDATE employees
SET email = ?, phone_number = ?
WHERE employee_id = ?
AND email = ?
AND phone_number = ?
In the preceding UPDATE statement, the email and phone number values in the WHERE clause are the original, unmodified values for the specified employee. This update ensures that the row
that the application modifies was not changed after the application last read and displayed it to the user. In this way, the application avoids the lost update database problem in which one user overwrites changes made by another user, effectively losing the
update by the second user (Table 9–2 on page 9-7 shows an example of a lost update).
Table 9–4 shows the sequence of events when two sessions attempt to modify the same row in the employees table at roughly the same time.
Oracle Database automatically obtains necessary locks when executing SQL statements. For example, before the database permits
a session to modify data, the session must first lock the data. The lock gives the session exclusive control over the data so that no other transaction can modify the locked data until the lock is released.
Because the locking mechanisms of Oracle Database are tied closely to transaction control, application designers need only define transactions properly, and Oracle Database automatically
manages locking. Users never need to lock any resource explicitly, although Oracle Database also enables users to lock data manually.
The following sections explain concepts that are important for understanding how Oracle Database achieves data concurrency.
Lock Modes
Oracle Database uses two modes of locking in a multiuser database:
■Exclusive lock mode
This mode prevents the associated resource from being shared. A transaction obtains an exclusive lock when it modifies data. The first transaction to lock a resource exclusively is the
only transaction that can alter the resource until the exclusive lock is released.
■Share lock mode
This mode allows the associated resource to be shared, depending on the operations involved. Multiple users reading data can share the data, holding share locks to prevent concurrent
access by a writer who needs an exclusive lock. Several transactions can acquire share locks on the same resource.
Assume that a transaction uses a SELECT ... FOR UPDATE statement to select a single table row. The transaction acquires an
exclusive row lock and a row share table lock. The row lock allows other sessions to modify any rows other than the locked row, while the table lock prevents sessions from altering the structure of the table. Thus, the database permits as many statements as
possible to execute.
Lock Conversion and Escalation
Oracle Database performs lock conversion as necessary. In lock conversion, the database automatically converts a table lock
of lower restrictiveness to one of higher restrictiveness.
For example, suppose a transaction issues a SELECT ... FOR UPDATE for an employee and later updates the locked row. In this case, the database automatically converts the row share table
lock to a row exclusive table lock. A transaction holds exclusive row locks for all rows inserted, updated, or deleted within the transaction. Because row locks are acquired at the highest degree of restrictiveness, no lock conversion is required or performed.
Lock conversion is different from lock escalation, which occurs when numerous locks are held at one level of granularity (for example, rows) and a database raises the locks to a higher
level of granularity (for example, table). If a user locks many rows in a table, then some databases automatically escalate the row locks to a single table. The number of locks decreases, but the restrictiveness of what is locked increases.
Oracle Database never escalates locks. Lock escalation greatly increases the likelihood of deadlocks. Assume that a system is trying to escalate locks on behalf of transaction 1 but cannot
because of the locks held by transaction 2. A deadlock is created if transaction 2 also requires lock escalation of the same data before it can proceed.
Lock Duration
Oracle Database automatically releases a lock when some event occurs so that the transaction no longer requires the resource.
In most cases, the database holds locks acquired by statements within a transaction for the duration of the transaction. These locks prevent destructive interference such as dirty reads, lost updates, and destructive DDL from concurrent transactions.
Oracle Database releases all locks acquired by the statements within a transaction when it commits or rolls back. Oracle Database
also releases locks acquired after a savepoint when rolling back to the savepoint. However, only transactions not waiting for the previously locked resources can acquire locks on the now available resources. Waiting transactions continue to wait until after
the original transaction commits or rolls back completely (see Table 10–2 on page 10-9 for an example).
Locks and Deadlocks
A deadlock is a situation in which two or more users are waiting for data locked by each other. Deadlocks prevent some transactions
from continuing to work.
Oracle Database automatically detects deadlocks and resolves them by rolling back one statement involved in the deadlock, releasing one set of the conflicting row locks. The database
returns a corresponding message to the transaction that undergoes statement-level rollback. The statement rolled back belongs to the transaction that detects the deadlock. Usually, the signalled transaction should be rolled back explicitly, but it can retry
the rolled-back statement after waiting.
Table 9–5 illustrates two transactions in a deadlock.
Deadlocks most often occur when transactions explicitly override the default locking of Oracle Database. Because Oracle Database
does not escalate locks and does not use read locks for queries, but does use row-level (rather than page-level) locking, deadlocks occur infrequently.
