Browse Prior Art Database

Methods for Space Management in Transaction Systems Supporting Fine-Granularity Locking

IP.com Disclosure Number: IPCOM000106265D
Original Publication Date: 1993-Oct-01
Included in the Prior Art Database: 2005-Mar-20
Document File: 4 page(s) / 242K

Publishing Venue

IBM

Related People

Haderle, DJ: AUTHOR [+2]

Abstract

In a transaction processing system, it is necessary to support rollback or undo of part or all of the actions executed as part of a recoverable transaction. When an action which may need to be undone has released some storage space, that space cannot be consumed by actions of other transactions without compromising the ability to undo the action which released the space. The methods disclosed here enable varying length records to be supported efficiently (e.g., as in System R and DB2) by permitting garbage collection to be performed within a page without the moved records having to be locked or the movements having to be logged. The latter are possible because locking and logging are done in a logical, rather than physical, manner.

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

Methods for Space Management in Transaction Systems Supporting Fine-Granularity Locking

      In a transaction processing system, it is necessary to support
rollback or undo of part or all of the actions executed as part of a
recoverable transaction.  When an action which may need to be undone
has released some storage space, that space cannot be consumed by
actions of other transactions without compromising the ability to
undo the action which released the space.  The methods disclosed here
enable varying length records to be supported efficiently (e.g., as
in System R and DB2) by permitting garbage collection to be performed
within a page without the moved records having to be locked or the
movements having to be logged.  The latter are possible because
locking and logging are done in a logical, rather than physical,
manner.  When space management is done in a flexible manner in
transaction systems, we need to be careful so that the following
sequence of actions is not possible: a transaction T1 performs an
operation (e.g., record delete) and frees up some space on page  P1;
before T1 terminates, T2 consumes that space and commits; T1 rolls
back and does not find enough free space on P1 to undo its original
operation.  If such a scenario is permitted, preserving transaction
semanics may not be possible.  The need to conserve released space
until the releasing transaction completes occurs whenever executing
actions manipulate the recoverable data structures directly.  Note
that when locking and logging are not physical in nature, the
(logical) locks obtained on records are not sufficient to ensure that
space freed by one transaction is not consumed by other transactions.
Something more needs to be done to "reserve" uncommitted freed space.
The objective of this disclosure is to address this problem.  In
contrast, in IMS, where physical locking and logging are done, the
locks obtained on a deleted record are sufficient to protect the
freed space.  Even there, when locking is done on records rather than
on segments, special logic is needed to reserve the space freed by
deleting a segment.

The following assumptions were made:

o   The granularity of locking is something finer than a page (e.g.,
    a record).

o   There are two fields in each page called TFS (Total Free Space)
    and CFS (Contiguous Free Space) which keep track of space
    availability on the page.  The CFS area is generally the free
    space that begins after the last record on the page and extends
    until the beginning of the trailer of the page.  The NFS
    (noncontiguous free space) is scattered in the area which begins
    after the header of the page and ends at the beginning of the
    last record on the page.  The total size of the NFS area is
    (TFS-CFS).  The different segments of free space that constitute
    the NFS may be chained together to easily locate them.

o   There are 2 bits on every page to track...