Browse Prior Art Database

High Concurrency Recoverable Space Management and Object Access

IP.com Disclosure Number: IPCOM000122186D
Original Publication Date: 1991-Nov-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 4 page(s) / 152K

Publishing Venue

IBM

Related People

Barnes, CC: AUTHOR [+2]

Abstract

A program is disclosed that minimizes delays between multiple concurrent units of work due to serialization requirements. Specifically, the serialization interval involved when processing a two-phase commit protocol is minimized. It concerns itself with two problem areas: 1. space management, and 2. object access.

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

High Concurrency Recoverable Space Management and Object Access

      A program is disclosed that minimizes delays between
multiple concurrent units of work due to serialization requirements.
Specifically, the serialization interval involved when processing a
two-phase commit protocol is minimized.  It concerns itself with two
problem areas:
1.  space management, and
2.  object access.

      Space management and object information (files, directories,
etc.) which is represented in nonvolatile storage by a space entry or
object entry, respectively, must be serialized at commit time to
ensure the change is made (committed) or not made (backed out) with
integrity.  When processing a one-phase commit, the interval of
serialization is negligible.  However, when a two-phase commit
protocol must be used, the interval of serialization is indeterminate
because multiple distributed resources are involved in the protocol.

      The process below addresses high concurrency for space
management by using a locking and recovery protocol that does not
require serialization for the duration of the two-phase commit.  The
result is that the delay to the user or application is negligible.
The process assumes that the unit of allocation of nonvolatile
storage of objects in a file space (the collection of a user's or
applications' objects and the nonvolatile storage that is used to
contain the objects) is a block of some fixed length.

      The description of the process assumes the following variables:
   DELTAUSED is the value that represents the delta number of blocks
in a file space used by a logical unit of work (LUW).  (An LUW is
a convenient abstraction for the application processing (including
the underlying system support) performed to take a set of resources
from one consistent state to another in such a way that the unit of
work appears to be atomic.  If a failure occurs during the processing
of an LUW, any changes made as part of the LUW are undone, so that
the resources are returned to a consistent state.)  DELTAUSED is
incremented or decremented as the logical unit of work uses or frees
space in a file space.  At commit time, the value represents the
result of all operations by the logical unit of work against the file
space.  It could be either 0, or positive when the logical unit of
work used additional space, or negative when it freed space.
     FSUSEDDASD is the value in nonvolatile storage (e.g., on DASD)
of the number of blocks in a file space that are used.
     FSUSEDINCORE is the value in volatile storage ("in core") of the
number of blocks in a file space that are used.

      The two variables, FSUSEDDASD and FSUSEDINCORE, are generally
equal and incremented with DELTAUSED at commit time.  This is part of
phase one of the two-phase commit protocol.  However, if the logical
unit of work freed space, the update to FSUSEDINCORE is deferred
until the end of phase two.  The exact difference betwe...