Browse Prior Art Database

Method for Callback Coordination and Sliver Condition Toleration in Distributed Environment

IP.com Disclosure Number: IPCOM000117106D
Original Publication Date: 1995-Dec-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 2 page(s) / 101K

Publishing Venue

IBM

Related People

Bennett, RB: AUTHOR [+3]

Abstract

Described is a method for coordinating concurrent token requests, awards, and callbacks, with toleration of sliver conditions in a distributed environment.

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

Method for Callback Coordination and Sliver Condition Toleration
in Distributed Environment

      Described is a method for coordinating concurrent token
requests, awards, and callbacks, with toleration of sliver conditions
in a distributed environment.

      The environment is one in which consistency and concurrency of
file system reads and writes of objects is controlled through award
and callback of tokens.  Token awards also protect cached information
in the environments of the participating clients.  When one such
token is awarded by the Token Manager of a common Repository File
Server to a first client for file A and a second client requires the
same token or a conflicting token for the same file, the server
"calls back" the token from the first client and, upon relinquishment
by that first client, awards it to the second client.

      In such a token managed system, sliver conditions may arise due
to the time lapse between the time of recording of a token award by a
common server and the time of receiving and recording that token
award by the requesting client.

      During such a time lapse, the server could receive a request
that requires this same token from a second client, realize that the
token has been awarded to the first client, then initiate a callback
to the first client.  In some cases it is possible for the token
callback to reach the first client before the response arrives to
indicate the token award.

      In another timing condition, a client could voluntarily give up
a token just before receiving a callback for that same token.  The
server does not know of the voluntary token relinquishment when it
generates a callback for the same token.

      When callbacks and/or voluntary relinquishment of tokens
involve more than one token for a single object, as with object and
block tokens, these same timing conditions or combinations thereof
can lead to partial not founds for the tokens requested by a
callback.

      For a variety of reasons, callback messages to a client holder
of a token or set of tokens can encounter a delayed response.  This
creates some additional problems for managing callbacks, such as when
to assume that a response is really not going to arrive and what to
do when getting a callback response after the originating server has
given up on the matter.

Following are elements of the solution to these problems:
  1.  maintenance of a record of token awards in a common server
       environment
  2.  awarding tokens requested by a first client when no other
client
       has been awarded the token or when another token award does
not
       conflict with such a token award
  3.  generating callback messages to clients that hold conflicting
       tokens, requiring them to respond by relinquishing the tokens.
       Such rel...