Browse Prior Art Database

Adaptive Lock Escalation/ De-escalation

IP.com Disclosure Number: IPCOM000106949D
Original Publication Date: 1992-Jan-01
Included in the Prior Art Database: 2005-Mar-21
Document File: 3 page(s) / 124K

Publishing Venue

IBM

Related People

Holm, ML: AUTHOR [+2]

Abstract

A method of file concurrency control is disclosed. The lock level dynamically changes between an object level and a more granular method depending on the type of operations being performed against the file.

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

Adaptive Lock Escalation/ De-escalation

       A method of file concurrency control is disclosed.  The
lock level dynamically changes between an object level and a more
granular method depending on the type of operations being performed
against the file.

      This invention describes a method to dynamically switch between
a file level lock and a record level lock (with extensions possible
for any lock granularity).  The locking method is changed as
concurrent update activity occurs.  The record level lock method is
used when there are updates in progress on a file.  When there are no
updates in progress, the job reading the file uses the file level
locking method. The method of locking can change dynamically.

      Users of the file are categorized into two types: Readers and
Updaters.  The following points describe how the concurrency is
managed for each type.

      UPDATER - Before updating a record, deleting a record, or
inserting a record into the file, an Intent Exclusive lock is
obtained on the file.  Before attempting the file lock, an "updater
count" is incremented for the particular file.  This count indicates
that an update is in progress if the lock is obtained; if the process
cannot get the Intent lock, it will be in a wait state.  A process
waiting for the file level Intent Exclusive lock with the updater
count incremented signifies an update is being attempted. Once the
update is complete and after the file lock is released, the updater
count gets decremented.

      As each record is being updated or deleted it is locked
exclusively by the task doing the update type operation.

      Updaters always operate in the above manner, which allows
concurrent insert, updates and deletes to occur.

      READER - A reader of a file may operate in one of two modes,
Concurrency, or Stand-alone.
      -  Reader in Concurrency mode
           -  An Intent Shared type lock is obtained on the file.
This type of lock will share with the Intent Exclusive lock obtained
by updaters.
           -  While in concurrency mode, the reader must use a
mechanism that ensures the record is not in the middle of an update.
This may be either a record lock, that conflicts with the Exclusive
obtained by updaters, or some kind of atomic copy that guarantees the
record is not in a changing state while mapping it to a private
buffer.
           -  Readers in concurrency mode can be accessing the file
simultaneously with updaters.
      -  Reader in Stand-alone mode.
           -  A SHARED type file level lock is obtained and nothing
is required at the record level to prevent updates from occurring on
each record as it is being read.
           -  This mode can be used by many readers of a file at the
same time.  It does, however, prevent updaters from accessing the
file.  It also gives the reader optimum performance since no work
needs to be done to man...