Browse Prior Art Database

Look Processing in a Shared Data Base Environment

IP.com Disclosure Number: IPCOM000045307D
Original Publication Date: 1983-Mar-01
Included in the Prior Art Database: 2005-Feb-06
Document File: 5 page(s) / 21K

Publishing Venue

IBM

Related People

Gawlick, D: AUTHOR

Abstract

A locking strategy is described which is dynamically and independently adaptable with respect to each of a plurality of data classes in a shared data base. Lock Manager Processing.

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

Page 1 of 5

Look Processing in a Shared Data Base Environment

A locking strategy is described which is dynamically and independently adaptable with respect to each of a plurality of data classes in a shared data base.

Lock Manager Processing.

A request for use of a resource may be issued by a work unit, such as a region in the IBM Information Management System (IMS/VS), to a lock manager, which generally must allow the request before the resource will be used by the work unit issuing the request. The work unit request may have to wait until some contention has been resolved. (There is an alternative not to do locking at all up to the commit process, as in the IMS/VS Fast Path implementation of Main Storage Data Bases (MSDBs). This "optimistic" approach assumes that resource conflicts are rare events. For MSDBs this approach is used to increase parallelism, since MSDBs allow arithmetic operations on data fields.)

If the process to acquire iocks is not CPU bounded (in the sense that all lock requests from a given work unit can be handled within one computer), but requires interaction between different computers, it may be advisable to overlap lock request processing with I/O processing. This may be advisable where (1) the rejection of a lock request is a rare event and the penalty to redo some work is smaller than the penalty to wait for the completion of the lock request, and (2) the work unit requesting a resource can redo some or all of its work and will not externalize any changes (i.e., write data to data bases or send messages) unless all outstanding requests have been granted.

Synchronous and Asynchronous Locking.

To allow the overlapping of lock request processing with I/O processing, the lock manager replies to a request in two steps.

Step 1: Accept the request. In synchronous lock processing, one of the following results is returned to the requestor: (a) wait until the request can be granted; or (b) go ahead upon confirmation. In asynchronous lock processing, the additional following result may be returned to the requestor if the requestor allows it: (c) go ahead without confirmation.

Step 2: Confirm the request. In the case of asynchronous processing, and following confirmation of the request, the requestor will be informed if the request is finally granted or denied. If the request is denied, the requestor may have to back out some or all of the work that it has done since the last commit process. If more than one resource request is outstanding for confirmation and there is a contention, the contention detection mechanism indicates which lock(s) have the conflict.

synchronous resource locking may be overlapped at two levels, as follows: 1. Overlap of locking and data base I/O only.

1

Page 2 of 5

This technique is useful under the assumption that a system locks on a data block (page). It allows overlapping of the WAIT time for the I/O operation with the WAIT time for the lock request handling. In case of a synchronous request, the r...