Oracle7 Parallel Server Concepts and Administrator's Guide Go to Product Documentation Library
Go to books for this product
Go to Contents for this book
Go to Index

Go to previous file in sequence Go to next file in sequence

Distributed Lock Manager: Access to Resources

This chapter explains the role of the DLM in controlling access to resources in a parallel server. The chapter is organized as follows:

What Is a Distributed Lock Manager?

A distributed lock manager (DLM) is a software component provided by your platform vendor. The DLM maintains a list of system resources and provides locking mechanisms to control allocation and modification of Oracle resources. DLM resources are logical concepts, structures of data. The DLM does not control access to tables or anything in the database itself. Every process interested in the database resource protected by the DLM must open a lock on the resource.

The Oracle Parallel Server uses a distributed lock manager to coordinate concurrent access to resources, such as data blocks and rollback segments, across multiple instances. Oracle Corporation has defined a DLM interface which a variety of vendors have implemented.

The DLM Grants and Converts Resource Lock Requests

The DLM coordinates lock requests, ensuring compatibility of access rights to the resources. In this process the DLM 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 DLM keeps an inventory of all these lock requests, and communicates their status to the users and processes involved.

Lock Requests Are Queued

The DLM 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 DLM uses two types of asynchronous traps (ASTs) or interrupts:

acquisition AST

When the lock is obtained, 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 lock on a resource, the DLM 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. Each resource in the DLM has an associated value tracked in the lock value block. If the caller of the DLM wishes to preserve this value when owners of locks on the resource die abnormally, then resource persistence is required. It ensures that the database resources protected by these locks can be recovered efficiently.

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

Check your operating system documentation to determine whether persistent resources are implemented in your DLM.

Lock Requests Are Converted and Granted

The following figures illustrate the way in which DLMs handle 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 DLM Granted and Convert Queues

The lock value block is normally an area of 16 bytes that is created when you allocate the resource in the DLM. It is a means of communicating the status of the lock between processes. For example, if process 1 owns the lock in exclusive mode, it can write some status information to the lock value block when it downconverts from X to N. When process 2 obtains the lock in exclusive mode, it will read the lock value block to obtain the last written value of the lock.

As illustrated in Figure 8 - 2, the DLM 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

DLM Lock Modes: Resource Access Rights

This section covers the following topics:

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.

DLM Lock Mode Names

The following figure illustrates the levels of access rights or "lock modes" which are available through the DLM.

Figure 8 - 4. DLM Lock Modes: Levels of Access


Null mode; corresponds to Oracle null mode (N). 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 DLM to be constantly creating and destroying locks when ongoing access is needed.


Concurrent read mode; corresponds to Oracle sub shared mode (SS). 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. Note: The DLM concurrent read mode (CR) should not be confused with the consistent read buffer state (also abbreviated as CR).


Concurrent write mode; corresponds to Oracle shared exclusive mode (SX). 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.


Protected read mode; corresponds to Oracle shared mode (S). 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.


Protected write mode; corresponds to Oracle sub-shared exclusive mode (SSX). 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.


Exclusive mode; corresponds to Oracle exclusive mode (X). 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.

Oracle vs. DLM Lock Mode Names

Oracle and most DLMs use different names to describe lock modes. Many DLMs use names based on the VAX lock manager modes. The following table shows the correspondence between Oracle lock mode names and typical lock mode names used by DLMs.

DLM Mode Oracle Mode Description
NULL NULL No lock is on the resource
CR SS Read; there may be writers and other readers
CW SX Write; there may be other readers and writers
PR S Read; no writers are allowed
PW SSX One writer only; there may be readers
EX X Write; no other access is allowed
Table 8 - 1. Oracle vs. DLM Lock Mode Names

Note that the Oracle modes listed here exist only in the context of the DLM. The Oracle7 Server Reference manual lists Oracle lock mode names you will normally encounter.

DLM Features

This section describes the following DLM features:

When planning a parallel system, take into consideration the features supported by the DLM component, to ensure that it will adequately meet your needs.

Distributed DLM

A distributed DLM removes a single point of failure, and therefore aids in fault tolerance. It ensures that the system can survive node crashes. Although you may be able to configure some DLMs so that they run only on a single node, this configuration is not supported.

Fault Tolerance

All distributed DLMs are not necessarily fault tolerant. If one node dies, the remaining node(s) should be able to rebuild the locks on another node. If the DLM is not fault tolerant, then Oracle Parallel Server will not be fault tolerant. In this case OPS will not be able to survive a node crash (that is, a DLM crash); it will, however, survive an instance crash.

Kernalized or User-level DLMs

DLMs may be implemented in user space (user-level DLMs), or they may be built in to the operating system (kernalized DLMs). Oracle Parallel Server fully supports both implementations.

Lock Mastering

In a distributed system the DLM must maintain information about the locks on all nodes that are interested in a given resource. In this situation, the DLM usually nominates one node to manage all relevant information about the resource and its locks. This is called the master node. The lock mastering implementation determines which node this will be.

The method of lock mastering used by your DLM has a number of implications. First, it has an impact on system performance. Oracle performance is optimized if certain locks (particularly non-PCM locks) are always mastered locally. Second, understanding how your DLM functions enables you to interpret phenomena that you will observe in your configuration. For example, if all locks are mastered on one node then all locks and resources will be created on that node during startup. This means that the second node to start up (and later nodes) must go to the first node to open the lock; you will thus observe a slower startup time for these nodes.

Three methods of lock mastering in the DLM are available:

static hashing

In static hashing the resource may be arbitrarily created on any particular node, either local or remote.

directory service

With directory service, every resource is created locally and its location is stored in a directory node from which it can be found. A process must always go first to the directory node to find out on which node the resource has been created.

dynamic mastering

With dynamic mastering a resource requested on one node is always migrated to that particular node; the system figures this out without recourse to the DLM.

Memory Requirements

DLMs differ in the total number of locks and other resources they can support. Kernalized DLMs may have a hard limit on the number of resources they can support. User-level DLMs 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 your DLM is configured to support all the resources which your application will require.

Deadlock Detection

Understanding the way in which your DLM performs deadlock detection will enable you to understand anomalies of performance which the user may see.

DLMs can perform deadlock detection in two ways:


In distributed deadlock detection, all deadlock sensitive locks and resources can be distributed. Deadlock detection thus becomes more expensive, because all nodes must be scanned for deadlocks.


With centralized deadlock detection, all lock requests must go to one particular node. This could mean that some users' deadlock-sensitive locks take longer to acquire (if the user does not happen to reside on the centralized deadlock node).

DLM Support for MTS and XA

Oracle Parallel Server supports two forms of lock ownership that may be available with your DLM:

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 shared by two or more processes belonging to the same group. Processes in the same group can share the lock without going to the DLM grant and convert queues.

Group-based locking is an important DLM feature if you wish to use Oracle multi-threaded server (MTS) or XA library functionality.


Group-based locking is strongly recommended for Oracle MTS configurations. Without it, sessions cannot 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 share the same locks, even in exclusive mode. With group-based lock ownership, processes can share access to an exclusive resource.

Evaluating a Distributed Lock Manager

This section covers the following topics:

How a DLM Implementation Impacts Oracle

The features of your system's DLM will have a noticeable effect on the performance of the Oracle Parallel Server.

Optimal DLM Features

For optimal performance of OPS, your vendor-supplied DLM should provide the following features:

Go to previous file in sequence Go to next file in sequence
Prev Next
Copyright © 1996 Oracle Corporation.
All Rights Reserved.
Go to Product Documentation Library
Go to books for this product
Go to Contents for this book
Go to Index