Browse Prior Art Database

INTER-SYSTEM LOCK MANAGEMENT WITHIN SINGLE REQUEST BONDS

IP.com Disclosure Number: IPCOM000013301D
Original Publication Date: 2001-May-01
Included in the Prior Art Database: 2003-Jun-18
Document File: 1 page(s) / 52K

Publishing Venue

IBM

Abstract

Limiting a lock manager for a subsystem to a single held lock indicator and a single pending request per lockable resource introduces problems that do not exist if the lock manager can have multiple requests per resource. Examples of these problems are resource starvation due to unfair inter-sytem lock processing, and deadlocks exclusively caused by the lock manager. Disclosed is a system that eliminates these problems through a combination of contention indicators, time-stamps, and careful use of the pending request.

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

Page 1 of 1

INTER-SYSTEM LOCK MANAGEMENT WITHIN SINGLE REQUEST BONDS

Limiting a lock manager for a subsystem to a single held lock indicator and a single pending request per lockable resource introduces problems that do not exist if the lock manager can have multiple requests per resource. Examples of these problems are resource starvation due to unfair inter-sytem lock processing, and deadlocks exclusively caused by the lock manager. Disclosed is a system that eliminates these problems through a combination of contention indicators, time-stamps, and careful use of the pending request.

    The notion of a held composite state is introduced. The held composite state is defined as the most restrictive state of the locks held on the resource by a given lock manager assuming the locks were all owned by the same unit of work.

    The notion of a requested composite state is introduced. The requested composite state is defined as the held composite state of a resource if the highest priority waiting request were granted.

The notion of a contention marker is introduced. A contention marker indicateds intersystem contention exists for a resource.

    The notion of a global manager is introduced. A global manager is an instance of the lock manager selected to do compatibility determination for a resource whenever inter-system interest in that resource exists (whenever two or more lock managers hold or are waiting for potentially incompatible locks on the same resource).

The following rules are used to determine when a request for a resource is sent to the global manager:

Lock Requests

           Lock requests will be sent to the global manager once they are locally compatible (i.e. there is no contention with locks managed by the lock manager on behalf of transactions on the

same system) when:

1. They represent an increase in the held compsite state of th...