Browse Prior Art Database

Implementation of an Optimistic Lock Mechanism for Persistent Objects Within an Object-Oriented Environment

IP.com Disclosure Number: IPCOM000119720D
Original Publication Date: 1991-Feb-01
Included in the Prior Art Database: 2005-Apr-02
Document File: 6 page(s) / 175K

Publishing Venue

IBM

Related People

Abraham, RL: AUTHOR [+3]

Abstract

Disclosed is a technique to prevent update collisions between multiple users of the same object within an object-oriented environment such that: collisions are not allowed to occur, corrective intervention is only required when a collision is prevented, and there is minor negative performance impact.

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

Implementation of an Optimistic Lock Mechanism for Persistent Objects
Within an Object-Oriented Environment

      Disclosed is a technique to prevent update collisions
between multiple users of the same object within an object-oriented
environment such that:
    collisions are not allowed to occur,
    corrective intervention is only required when a
    collision is prevented, and
    there is minor negative performance impact.

      An update collision occurs when two copies of the same object
are in use at the same time and after one copy is used to update
the object in the database, the other copy is also used to update the
database.  The first update has been overlaid by the second update.

      There are a number of traditional locking mechanisms which
require the user to specify a particular lock type on the data before
accessing and updating the data.  These types of locks present a lot
of problems, namely, the programming, processing, and administrative
overhead associated with having to explicitly lock and unlock data
elements.

      The Optimistic Lock mechanism presented in this article is a
locking mechanism which assumes that collisions will occur on an
infrequent basis.  If the chance of an update collision is small,
then this locking mechanism is very efficient.  In theory, an
optimistic lock is just as its name implies.  The optimistic lock
"optimistically" assumes that the object in use will suffer no update
collision when it is written back to the database.  This assumption
allows lock checks to be deferred to the latest possible moment, that
is, there is no need to check locks when the object is initially read
from the database but only when the object is to be written back to
the database.  This is particularly useful in a CUA environment where
"open" is used instead of "view" and "change".

      The key to optimistic locking is in verifying that the object
in the database is in fact exactly the same as the object which was
read initially into memory and modified. If the object in the
database is the same as was initially read into memory, then the
updated object may safely be written to the database, overlaying the
object already there.  However, if it is determined that the object
in the database is a different, usually later version of the object
which was read and updated, then it is considered unsafe to update
the database with the copy in memory.  An update collision has
occurred.

      The Optimistic Lock mechanism described in this article uses a
date-time stamp to determine the correlation of the object in the
database with the updated copy of the object in memory.  This
date-time stamp represents the last time the object was written to
the database.  When the object is read from the database, this
date-time stamp is read right along with it.  It is considered an
integral part of the object, that is, it is an instance attribute of
every persistent object.

   ...