Browse Prior Art Database

Configurable Lock Manager

IP.com Disclosure Number: IPCOM000201701D
Publication Date: 2010-Nov-18
Document File: 4 page(s) / 31K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a protocol whereby a middleware product that wants to use a common Lock Manager as a service is able to describe to the Lock Manager the behavior that it needs for its locking operations.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 33% of the total text.

Page 01 of 4

Configurable Lock Manager

A Lock Manager is generally a component of a middleware software product and is used to lock shared data objects in a variety of Lock Modes.

In some file systems a file can be opened by multiple readers at the same time; however, only one writer is allowed to open the file and while the writer holds the file open no other reader can open the file. These rules are represented in the form of a compatibility matrix in Figure 1.

Figure 1: Compatibility Matrix

To enforce these rules using a matrix, the X axis represents the mode in which a lock is currently held. The Y axis represents the Lock Mode in which the lock has been requested. If M[x, y] yields "Yes" then the lock may be granted in the requested mode. Many database managers use about a dozen different Lock Modes.

Most database management systems and messaging systems include as one of their components a Lock Manager that is written specifically for their needs. At a high level, these Lock Managers all provide the same function. But the details of their operation, the Lock Modes that they support, and their compatibility matrices are designed only to operate with the particular product of which they are a part. As currently designed, it is not possible to take the Lock Manager from one of these products and make it work with another product.

Many products have a compatibility matrix built into the Lock Manager. A compatibility matrix defines those lock modes that are compatible with each other. Two modes (m1 and m2) are compatible with each other if they may each be held at the same time by two different transactions. If they are not compatible with each other, then they are said

1

Requested

Mode

R

W

Currently held mode

R

W

Yes

No

No

No



Page 02 of 4

to conflict. Other mode relationships include:

Dominates: Given two modes (m1 and m2), m1 is said to dominate m2 if holding m1 restricts concurrency at least as much as holding m2. If every mode that conflicts with m1 also conflicts with m2, then m1 is said to dominate m2. Holding m1 ensures that the holder will conflict with any holder that conflicts with m2.

Least Upper Bound (LUB): Given two modes (m1 and m2), find all other lock modes that dominate both of them. Call this set of modes Q. The lock mode in set Q that has the smallest number of conflicting modes is said to be the Least Upper Bound (LUB) of modes m1 and m2. The LUB operation is both associative and commutative.

Greatest Lower Bound (GLB): Given two modes (m1 and m2), find all other lock modes that both of them dominate. Call this set of modes Q. The lock mode in set Q that has the largest number of conflicting modes is said to be the Greatest Lower Bound (GLB) of modes m1 and m2. The GLB operation is both associative and commutative.

Computing the dominates, LUB, and GLB functions involves searching through a number of lock modes. Given that all of these operations accept two integers as input and yield a binary result, it is a common prac...