Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Solving Time of Day Problems when Using DB2 Timestamp in Optimistic Lock Implementation

IP.com Disclosure Number: IPCOM000109070D
Original Publication Date: 1992-Jul-01
Included in the Prior Art Database: 2005-Mar-23
Document File: 3 page(s) / 88K

Publishing Venue

IBM

Related People

Okruw, SK: AUTHOR

Abstract

In object-oriented programming techniques, objects or data are materialized into memory and the database locks on the data released. The data is worked on for extended periods of time and, at time of updating the database an associated timestamp, which is stored in the database and also copied into memory with the data, is compared for equality before the update is allowed. Different timestamps on the data in memory and that in the database means that the data has been modified by some other user in the interim. If the timestamps match, then the data is updated and a new timestamp is created for the object. This is known as optimistic locking.

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

Solving Time of Day Problems when Using DB2 Timestamp in Optimistic Lock Implementation

       In object-oriented programming techniques, objects or
data are materialized into memory and the database locks on the data
released.  The data is worked on for extended periods of time and, at
time of updating the database an associated timestamp, which is
stored in the database and also copied into memory with the data, is
compared for equality before the update is allowed.  Different
timestamps on the data in memory and that in the database means that
the data has been modified by some other user in the interim.  If the
timestamps match, then the data is updated and a new timestamp is
created for the object.  This is known as optimistic locking.

      In situations where the clock is set back (e.g., daylight
saving time), it is possible for the two timestamps to match even
though the object has been updated in the interim.  This can happen
because the new timestamp created when the object is updated may
equal or lag behind the original timestamp in the database.  Such a
situation creates an opportunity for the new timestamp in the
database to match the original timestamp carried in memory by another
user.

      Consider User A and User B both materialize object X with
timestamp of 11.5 into memory at time 12.  At time 12 the clock is
set back an hour causing present time to change to 11.  At 11.5 User
A updates the object causing the timestamp in the database to become
11.5.  This timestamp is the same as that of the copy of the object
that User B has in memory causing User B's update to the same object
at a later time to be successful even though the object has been
modified in the interim.  Such a scenario will lead to the corruption
of the data in the database.

      The disclosed timestamp correction in optimistic locking
mechanism to solve the problem stated above therefore has the
following minimum characteristics:
      update the object in the database ensuring that the timestamp
in memory is equal to that in the database for the object;
      retrieve new timestamp from the database;
    ...