Locking Data Explicitly

transactions, serializable transactions, or overriding default locking for the system.

■A transaction requires exclusive access to a resource. To proceed with its statements, the transaction with exclusive access to a resource does not have to wait for other transactions to complete.

The automatic locking mechanisms can be overridden at the transaction level. Transactions including the following SQL commands override Oracle Database's default locking:

■LOCK TABLE

■SELECT, including the FOR UPDATE clause

■SET TRANSACTION with the READ ONLY or ISOLATION LEVEL SERIALIZABLE options

Locks acquired by these statements are released after the transaction is committed or rolled back.

The following sections describe each option available for overriding the default locking of Oracle Database. The initialization parameter DML_LOCKS determines the maximum number of DML locks allowed.

See Also: Oracle Database Reference for a discussion of parameters

Although the default value is usually enough, you might need to increase it if you use additional manual locks.

Caution: If you override the default locking of Oracle Database at any level, be sure that the overriding locking procedures operate correctly: Ensure that data integrity is guaranteed, data concurrency is acceptable, and deadlocks are not possible or are appropriately handled.

Choosing a Locking Strategy

A transaction explicitly acquires the specified table locks when a LOCK TABLE statement is executed. A LOCK TABLE statement manually overrides default locking. When a LOCK TABLE statement is issued on a view, the underlying base tables are locked. The following statement acquires exclusive table locks for the EMP_TAB and DEPT_TAB tables on behalf of the containing transaction:

How Oracle Database Processes SQL Statements 5-11

Locking Data Explicitly

LOCK TABLE Emp_tab, Dept_tab

IN EXCLUSIVE MODE NOWAIT;

You can specify several tables or views to lock in the same mode; however, only a single lock mode can be specified for each LOCK TABLE statement.

Note: When a table is locked, all rows of the table are locked. No other user can modify the table.

You can also indicate if you do or do not want to wait to acquire the lock. If you specify the NOWAIT option, then you only acquire the table lock if it is immediately available. Otherwise an error is returned to notify that the lock is not available at this time. In this case, you can attempt to lock the resource at a later time. If NOWAIT is omitted, then the transaction does not proceed until the requested table lock is acquired. If the wait for a table lock is excessive, then you might want to cancel the lock operation and retry at a later time; you can code this logic into your applications.

When to Lock with ROW SHARE and ROW EXCLUSIVE Mode

LOCK TABLE Emp_tab IN ROW SHARE MODE;

LOCK TABLE Emp_tab IN ROW EXCLUSIVE MODE;

ROW SHARE and ROW EXCLUSIVE table locks offer the highest degree of concurrency. You might use these locks if:

■Your transaction needs to prevent another transaction from acquiring an intervening share, share row, or exclusive table lock for a table before the table can be updated in your transaction. If another transaction acquires an intervening share, share row, or exclusive table lock, no other transactions can update the table until the locking transaction commits or rolls back.

■Your transaction needs to prevent a table from being altered or dropped before the table can be modified later in your transaction.

When to Lock with SHARE Mode

LOCK TABLE Emp_tab IN SHARE MODE;

SHARE table locks are rather restrictive data locks. You might use these locks if:

■Your transaction only queries the table, and requires a consistent set of the table data for the duration of the transaction.

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

Locking Data Explicitly

■You can hold up other transactions that try to update the locked table, until all transactions that hold SHARE locks on the table either commit or roll back.

■Other transactions may acquire concurrent SHARE table locks on the same table, also allowing them the option of transaction-level read consistency.

Caution: Your transaction may or may not update the table later in the same transaction. However, if multiple transactions concurrently hold share table locks for the same table, no transaction can update the table (even if row locks are held as the result of a SELECT... FOR UPDATE statement). Therefore, if concurrent share table locks on the same table are common, updates cannot proceed and deadlocks are common. In this case, use share row exclusive or exclusive table locks instead.

For example, assume that two tables, EMP_TAB and BUDGET_TAB, require a consistent set of data in a third table, DEPT_TAB. For a given department number, you want to update the information in both of these tables, and ensure that no new members are added to the department between these two transactions.

Although this scenario is quite rare, it can be accommodated by locking the DEPT_ TAB table in SHARE MODE, as shown in the following example. Because the DEPT_ TAB table is rarely updated, locking it probably does not cause many other transactions to wait long.

How Oracle Database Processes SQL Statements 5-13

Locking Data Explicitly

Note: You may need to set up data structures similar to the following for certain examples to work:

CREATE TABLE dept_tab( deptno NUMBER(2) NOT NULL, dname VARCHAR2(14),

loc VARCHAR2(13));

CREATE TABLE emp_tab ( empno NUMBER(4) NOT NULL, ename VARCHAR2(10),

job VARCHAR2(9), mgr NUMBER(4), hiredate DATE, sal NUMBER(7,2), comm NUMBER(7,2), deptno NUMBER(2));

CREATE TABLE Budget_tab ( totsal NUMBER(7,2),

deptno NUMBER(2) NOT NULL);

LOCK TABLE Dept_tab IN SHARE MODE;

UPDATE Emp_tab

SET sal = sal * 1.1

WHERE deptno IN

(SELECT deptno FROM Dept_tab WHERE loc = 'DALLAS');

UPDATE Budget_tab

SET Totsal = Totsal * 1.1

WHERE Deptno IN

(SELECT Deptno FROM Dept_tab WHERE Loc = 'DALLAS');

COMMIT; /* This releases the lock */

When to Lock with SHARE ROW EXCLUSIVE Mode

LOCK TABLE Emp_tab IN SHARE ROW EXCLUSIVE MODE;

You might use a SHARE ROW EXCLUSIVE table lock if:

■Your transaction requires both transaction-level read consistency for the specified table and the ability to update the locked table.

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