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

Method for Protecting Request Atomicity in Multi-Writer Distributed Environment

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

Publishing Venue

IBM

Related People

Bennett, RB: AUTHOR [+3]

Abstract

A method for protecting application request atomicity in a distributed file system environment is described. Responsive to application 103A requests by a participating client 101, changes to objects in a distributed file system must complete atomically (as a unit) or as a self-contained transaction before the results of that change is viewed by other clients 102 or before changes are allowed by other clients 102. This atomicity of requests provides a level of change consistency that is required by many shared file systems.

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

Method for Protecting Request Atomicity in Multi-Writer Distributed
Environment

      A method for protecting application request atomicity in a
distributed file system environment is described.  Responsive to
application 103A requests by a participating client 101, changes to
objects in a distributed file system must complete atomically (as a
unit) or as a self-contained transaction before the results of that
change is viewed by other clients 102 or before changes are allowed
by other clients 102.  This atomicity of requests provides a level of
change consistency that is required by many shared file systems.

      Each client 101 or 102 request to write or read an object can
encompass one or multiple requests (steps 1, 5, and 6) to a common
file server 200, where the accessed object is managed and stored.
Metadata in the form of an Object Cache Record 105, that describes
each object, and data blocks 106 (for files that can be read ahead
and associated with the metadata) are cached in each client
environment to avoid unnecessary server communications.

      In connection with obtaining Object Cache Records 105 and data
blocks 106 for an object from the server 200, the client 101 is
awarded a token to both represent that metadata and be used to
protect the atomicity of requests from client 101, that operate on
the object of that metadata.  The token award for a particular cached
object metadata often occurs in conjunction with supplying metadata
to the client environment, typically as a special "lookup" request
(step 1) to resolve the path name element for that object.  Server
requests, such as the lookup request (step 1) to the server, are
originated by a Client Request Handler 106A.  Such a lookup request
goes to the server Request Manager 201, which reads the object
metadata from DASD 300 (Step 1A), utilizes (step 2) a server Token
Manager 202 to determine that the object token is available (and
record the token award), then responds (step 3) to the client with
the requested metadata and associated token award notification.  The
token award is represented by an indicator in the cached object
(Object Cache Record) 105.

      When subsequent requests from the holder of an object token,
such as represented by step 4, operate on an object that is
represented by an instance of a Object Cache Record 105, the
atomicity of that request is ensured by not relinquishing the token
tha...