Browse Prior Art Database

Two-Level Locking Protocol to Reduce Intersystem Communications

IP.com Disclosure Number: IPCOM000101674D
Original Publication Date: 1990-Aug-01
Included in the Prior Art Database: 2005-Mar-16
Document File: 3 page(s) / 167K

Publishing Venue

IBM

Related People

Dias, DM: AUTHOR [+3]

Abstract

A technique is described whereby a two-level locking protocol provides a means of locking and unlocking requests for data among computer systems. The two-level protocol provides good lock response time and reduces the communications overhead between multiple systems.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 35% of the total text.

Two-Level Locking Protocol to Reduce Intersystem Communications

       A technique is described whereby a two-level locking
protocol provides a means of locking and unlocking requests for data
among computer systems.  The two-level protocol provides good lock
response time and reduces the communications overhead between
multiple systems.

      As processing power of computer systems increases, the need
also increases to couple multiple systems together, requiring a
global locking protocol to serialize the access of data among
interconnected systems.  Lock requests are used to control the access
and can have different modes, such as shared and exclusive.  A
single-level locking approach may be implemented on a lock engine
that checks for compatibility, grants lock requests and processes
unlock requests.  The time required to respond to a lock request is
determined by the number of instructions required to perform a table
search and compatibility check.  The two-level protocol described
herein provides a means of improving the response time and reduces
communications overhead, as compared to the single level approach.
The top level of the two-level protocol has the ability to lock and
unlock requests quickly, while the bottom level is mainly used when
more than one request occurs and handles compatibility checking and
queueing.

      When a transaction requires a lock, a request is sent to level
1 to provide the name of the entity to be locked. If the level does
not contain the entity, the entity name and the requestors
identification is entered into level 1, an acknowledgement (ACK) is
returned synchronously and the transaction processing continues.  If
the entity name was already in level 1, a non-acknowledgement (NAK)
is returned. The system realizes that the transaction has a potential
conflict with some other transaction, sends the same lock request
over to level 2 indicating that it received a NAK from level 1 and
suspends the transaction to wait for granting the lock by level 2.
The action level 2 depends upon whether the lock entity state has
already surfaced to level 2 due to previous contention on that
entity.  Assuming the entity state is unknown to level 2, it will
issue a request to level 1 to obtain the current state of the locked
entity and changes the ownership of the locked entity in level 1 to
level 2.

      If the state information indicates that the entity is no longer
locked, in that the lock was released between the times the
transaction made requests to level 1 and level 2 reads the state from
level 1, level 2 will make the transaction the sole owner of the lock
in its lock table and grant the lock request.  Otherwise, level 2
will first record the original holder in level 1 as the owner of the
lock and then examine the compatibility of the transactions request.
Only if the request is compatible with the current locked state will
the request be granted.  Should an incompatible case occur, the...