8
Integrated Distributed Lock Manager

This chapter explains the role of the Integrated Distributed Lock Manager (IDLM) in controlling access to Oracle Parallel Server (OPS) resources by covering the following topics:

• What Is the Integrated Distributed Lock Manager?

• The IDLM Grants and Coordinates Resource Lock Requests

• IDLM Lock Modes: Resource Access Rights

• IDLM Features

What Is the Integrated Distributed Lock Manager?

The IDLM component of Oracle8 maintains a list of system resources and provides locking mechanisms to control allocation and modification of Oracle resources. IDLM resources are logical concepts; structures of data. The IDLM does not control access to tables or objects in the database itself. Every process interested in a database resource protected by the IDLM must open a lock on the resource.

OPS uses the IDLM to coordinate concurrent access across multiple instances to resources such as data blocks and rollback segments.

The IDLM Grants and Coordinates Resource Lock Requests

This section explains how the IDLM coordinates resource lock requests by explaining the following topics:

• Lock Requests Are Queued

• Asynchronous Traps (ASTs) Communicate Lock Request Status

• Lock Requests Are Converted and Granted

The IDLM coordinates lock requests, ensuring compatibility of resource access rights. In this process the IDLM tracks all lock requests. Requests for available resources are granted and access rights granted are tracked. Requests for resources not currently available are tracked, and access rights are granted when these resources later become available. The IDLM inventories these lock requests and communicates their statuses to users and processes involved.

Lock Requests Are Queued

The IDLM maintains two queues for lock requests:

Granted queue

The IDLM tracks lock requests that have been granted in the granted queue.

Asynchronous Traps (ASTs) Communicate Lock Request Status

To communicate the status of lock requests, the IDLM uses two types of asynchronous traps (ASTs) or interrupts:

Blocking AST

When a process requests a certain mode of lock on a resource, the IDLM sends a blocking AST to notify processes currently owning locks on that resource in incompatible modes. (Shared and exclusive modes, for example, are incompatible.) Upon notification, owners of locks can relinquish them to permit access by the requestor.

Lock Requests Are Converted and Granted

The following figures show how the IDLM handles lock requests.

In Figure 8-1, shared lock request 1 has been granted on the resource to process 1, and shared lock request 2 has been granted to process 2. As mentioned, IDLM tracks the locks in the granted queue. When a request for an exclusive lock is made by process 2, it must wait in the convert queue.

Figure 8-1 The IDLM Granted and Convert Queues

In Figure 8-2, the IDLM sends a blocking AST to Process 1, the owner of the shared lock, notifying it that a request for an exclusive lock is waiting. When the shared lock is relinquished by Process 1, it is converted to a null mode lock or released.

Figure 8-2 Blocking AST

An acquisition AST is then sent to wake up Process 2, the requestor of the exclusive lock. The IDLM grants the exclusive lock and converts it to the granted queue. This is illustrated below in Figure 8-3.

Figure 8-3 Acquisition AST

IDLM Lock Modes: Resource Access Rights

Instances use locks to obtain various rights to a resource. A lock may be initially created on a resource with no access rights granted. Later, a process converts the lock to obtain new access rights.

Figure 8-4 illustrates the levels of access rights or "lock modes" available through the IDLM.

Figure 8-4 IDLM Lock Modes: Levels of Access

Table 8-1 Lock Mode Names

Oracle Mode	Summary	Description
NULL	Null mode. No lock is on the resource.	Holding a lock at this level conveys no access rights. Typically, a lock is held at this level to indicate that a process is interested in a resource. Or it is used as a place holder. Once created, null locks ensure the requestor always has a lock on the resource; there is no need for the IDLM to constantly create and destroy locks when ongoing access is needed.
SS	Sub-shared mode (concurrent read). Read; there may be writers and other readers.	When a lock is held at this level, the associated resource can be read in an unprotected fashion: other processes can read and write the associated resource.
SX	Shared exclusive mode (concurrent write). Write; there may be other readers and writers.	When a lock is held at this level, the associated resource can be read or written in an unprotected fashion: other processes can both read and write the resource.
S	Shared mode (protected read). Read; no writers are allowed.	When a lock is held at this level, a process cannot write the associated resource. Multiple processes can read the resource. This is the traditional shared lock. In shared mode, any number of users can have simultaneous read access to the resource. Shared access is appropriate for read operations.
SSX	Sub-shared exclusive mode (protected write). One writer only; there may be readers	Only one process can hold a lock at this level. This allows a process to modify a resource without allowing other processes to simultaneously modify the resource at the same time. Other processes can perform unprotected reads. The traditional update lock.
X	Exclusive mode. Write; no other access is allowed	When a lock is held at this level, it grants the holding process exclusive access to the resource. Other processes cannot read or write the resource. This is the traditional exclusive lock.

IDLM Features

This section describes the following features of the IDLM:

• Distributed Architecture

• Fault Tolerance

• Lock Mastering

• Deadlock Detection

• Lamport SCN Generation

• Group-owned Locks

• Persistent Resources

• Memory Requirements

• Support for MTS and XA

• Views to Monitor IDLM Statistics

Distributed Architecture

The IDLM maintains a database of resources and locks held on these resources in different modes. This lock database resides in volatile memory and is distributed.

The IDLM has a distributed architecture. In the distributed architecture each node in the cluster (or each OPS instance of an Oracle database) participates in global lock management and manages a piece of the global lock database. The lock database is distributed among all participants. This distributed lock management scheme provides fault tolerance and enhanced runtime performance.

Fault Tolerance

The IDLM is fault tolerant in that it provides continual service and maintains the integrity of the lock database in the event of multiple node and OPS instance failures. A database is accessible as long as at least one OPS instance is active on that database after recovery completes.

Fault tolerance also enables OPS instances to be started and stopped at any time, in any order. However, instance reconfiguration may cause a brief delay.

Lock Mastering

The IDLM maintains information about locks on all nodes that need access to a particular resource. The IDLM usually nominates one node to manage all relevant information about a resource and its locks. This is node called the "master node".

OPS uses a static hashing lock mastering scheme. This mastering process hashes the resource name to one of the OPS instances that acts as the master for the resource. This results in an even, arbitrary distribution of resources across all available nodes. Every resource is associated with a master node.

The IDLM optimizes the method of lock mastering used in each situation. The method of lock mastering affects system performance during normal runtime activity as well as during instance startup. Performance is optimized when a resource is mastered locally.

When a resource is mastered remotely, all conflicting accesses to this resource result in the transmission of messages to the master node for this resource. This increases internode message traffic and affects system performance.

Deadlock Detection

IDLM performs deadlock detection to all deadlock sensitive locks and resources.

Lamport SCN Generation

OPS uses the fast and scalable Lamport SCN generation scheme that can generate SCNs in parallel on all instances.

See Also: "Lamport SCN Generation".

Group-owned Locks

Group-based locking provides dynamic ownership: a single lock can be shared by two or more processes belonging to the same group. Processes in the same group can share and/or touch the lock without opening or converting a new and different lock.

See Also: "Support for MTS and XA".

Persistent Resources

The IDLM provides persistent resources. Resources maintain their state even if all processes or groups holding a lock on it have died abnormally.

See Also: "Lock Requests Are Converted and Granted".

Memory Requirements

The user-level IDLM can normally allocate as many resources as you request; your process size, however, will increase accordingly. This is because you are mapping the shared memory where locks and resources reside into your address space. Thus, the process address space can become very large.

Make sure that the IDLM is configured to support all resources your application requires.

Support for MTS and XA

OPS uses two forms of lock ownership:

Per-process ownership	Locks are commonly process-owned: that is, if one process owns a lock exclusively, then no other process can touch the lock.
Group-based ownership	With group-based locking, ownership becomes dynamic: a single lock can be exchanged by two or more processes belonging to the same group. Processes in the same group can exchange and/or touch the lock without going to the IDLM grant and convert queues.

Group-based locking is an important IDLM feature for Oracle multi-threaded server (MTS) and XA library functionality.

MTS	Group-based locking is used for Oracle MTS configurations. Without it, sessions could not migrate between shared server processes. In addition, load balancing may be affected, especially with long running transactions.
XA libraries	With Oracle XA libraries, multiple sessions or processes can work on the transaction; they therefore need to exchange the same locks, even in exclusive mode. With group-based lock ownership, processes can exchange access to an exclusive resource.

Views to Monitor IDLM Statistics

Table 8-2 describes six dynamic performance views you can use to monitor IDLM statistics.

Table 8-2 Views to Monitor IDLM Statistics

View	Description
V$DLM_CONVERT_LOCAL	Shows the convert time for local lock convert operations. Enabled by Event 29700.
V$DLM_CONVERT_REMOTE	Shows the convert time for remote lock convert operations. Enabled by event 29700.
V$DLM_LOCKS	Contains debugging information about all locks currently known to the IDLM that are being blocked or are blocking others.
V$DLM_ALL_LOCKS	Contains debugging information about all locks currently known to the IDLM.
V$DLM_RESS	Contains statistics about resources being used by all locks.
V$DLM_MISC	Contains various IDLM statistics.

See Also: Please refer to the Oracle8 Reference for a complete description of these dynamic performance views.

---