8
Integrated Distributed Lock Manager: Access to Resources

This chapter explains the role of the Integrated Distributed Lock Manager (Integrated DLM, or IDLM) in controlling access to resources in a parallel server. The chapter is organized as follows:

What Is the Integrated Distributed Lock Manager?

The Integrated Distributed Lock Manager 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 anything in the database itself. Every process interested in the database resource protected by the IDLM must open a lock on the resource.

Oracle Parallel Server uses the IDLM facility to coordinate concurrent access to resources, such as data blocks and rollback segments, across multiple instances. The Integrated Distributed Lock Manager facility has replaced the external Distributed Lock Manager which was used in earlier releases of Oracle Server.

The Integrated DLM Grants and Converts Resource Lock Requests

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

Lock Requests Are Queued

The IDLM maintains two queues for lock requests:

convert queue	If a lock request cannot be granted immediately, it is placed in the convert queue, where waiting lock requests are tracked.
granted queue	Lock requests that have been granted are tracked 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:

acquisition AST	When the lock is obtained in the requested mode, an acquisition AST (a "wakeup call") is sent to tell the requestor that the requestor owns the lock.
blocking AST	When a process requests a certain mode of lock on a resource, the IDLM sends a blocking AST to notify processes which currently own 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.

Persistent Resources Ensure Efficient Recovery

The term "persistent resource" refers to the ability of a resource to maintain a particular state if all processes or groups holding a lock on it have died abnormally. This contrasts with normal resources, which cease to exist when there are no longer any owners of locks on that resource, regardless of how they exited.

Resource persistence is necessary for fine grain locking. It ensures that the database resources protected by these locks can be recovered correctly and efficiently.

Note: Not all resource information is kept after failures, only adequate information to protect resources during recovery.

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. The locks are tracked 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

As illustrated 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 exclusive lock is granted and it is converted to the granted queue. This is illustrated in Figure 8-3.

Figure 8-3: Acquisition AST

Integrated DLM Lock Modes: Resource Access Rights

Locks are used to obtain various rights to a resource. A lock may be initially created on a resource with no access rights granted. Later, a process will convert a lock to obtain new access rights.

Figure 8-4 illustrates the levels of access rights or "lock modes" which are 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 that the requestor always has a lock on the resource; there is no need for the IDLM to be constantly creating and destroying 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, no process can write the associated resource. There can be multiple processes reading 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 any other process to modify the resource at the same time. Other processes can perform unprotected reads. This is 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. No other process may read or write the resource. This is the traditional exclusive lock.

Integrated DLM Features

This section describes the following features of the Integrated DLM:

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 Integrated DLM 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 the participants. This distributed lock management scheme provides fault tolerance and enhanced runtime performance.

Fault Tolerance

The Integrated DLM is fault tolerant: it provides continual service and maintains the integrity of the lock database in the event of multiple node and OPS instance failures. Instance reconfiguration may cause a brief delay. A database is accessible as long as there is at least one OPS instance that 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.

Lock Mastering

In a distributed system the IDLM must maintain information about the locks on all nodes that are interested in a given resource. In this situation, the IDLM usually nominates one node to manage all relevant information about the resource and its locks. This is called the master node.

Two methods of lock mastering are currently available:

static hashing	The resource name is hashed to one of the OPS instances, which acts as the master for this resource. This scheme results in an even arbitrary distribution of resources across all available nodes. In this scheme, the directory node is also the master node for a resource.
dynamic hashing	The node that opens the first lock on a resource is nominated to be the master node for this resource. This information is stored at the directory node for the resource. In this scheme, the directory node may not be the master node for a resource.

The Integrated DLM optimizes the method of lock mastering to use in each situation. The method of lock mastering has an impact on 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 a message to the master node for this resource, which results in internode message traffic and impacts system performance.

Associated with every resource is a directory node and a master node. The directory node is derived from the resource name (the resource name is hashed to one of the active nodes in the cluster). The directory node maintains information about the node on which a resource is mastered. The node that masters a resource is the master node for the resource. Each node acts as the directory node for a subset of resources. In this sense, the directory service is distributed across all nodes in the cluster.

Deadlock Detection

IDLM performs distributed deadlock detection, in which all deadlock sensitive locks and resources can be distributed.

Lamport SCN Generation

Oracle Parallel Server uses the fast and scalable Lamport SCN generation scheme, which can generate SCNs in parallel on all instances.

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 going to the IDLM grant and convert queues.

Persistent Resources

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

Memory Requirements

The user-level Integrated DLM 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. The process address space can become very large.

Make sure that the IDLM is configured to support all the resources which your application will require.

Support for MTS and XA

Oracle Parallel Server 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 Integrated DLM Statistics

Four dynamic performance views are available to monitor Integrated DLM statistics. These are:

Table 8-2: Views to Monitor Integrated DLM Statistics

View	Description
V$DLM_CONVERT_LOCAL	Shows the convert time for local lock convert operations
V$DLM_CONVERT_REMOTE	Shows the convert time for remote lock convert operations
V$DLM_LATCH	Contains statistics about Integrated DLM latch performance. For each type of latch this table shows total gets and immediate gets. Ideally, IMM_GETS/TTL_GETS should be as close to 1 as possible.
V$DLM_MISC	Contains various Integrated DLM statistics.

See Also: Oracle8 Server Reference Manual for a complete description of these dynamic performance views.

8 Integrated Distributed Lock Manager: Access to Resources