Browse Prior Art Database

Browse Facility for a Performance Sensitive System

IP.com Disclosure Number: IPCOM000116571D
Original Publication Date: 1995-Oct-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 4 page(s) / 121K

Publishing Venue

IBM

Related People

Bolam, SW: AUTHOR

Abstract

Typically a component within a software product will be responsible for managing a number of objects. If the user, or another component, wishes to know which objects are currently in existence then the component needs to provide a browse facility.

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

Browse Facility for a Performance Sensitive System

      Typically a component within a software product will be
responsible for managing a number of objects.  If the user, or
another component, wishes to know which objects are currently in
existence then the component needs to provide a browse facility.

      It is usual for the component to maintain a global chain which
contains each of the current objects.  Typically this chain is
ordered (e.g., alphabetically by object name) and the browse will
return the objects in this order by traversing down the chain on each
'get next' request of the browse.  The progress of the browse being
recorded by a 'browse cursor' which points at the last object that
has been returned.

      The global chain can change whilst the browse is in progress
with objects being added to or removed from the chain.  In a
multi-task environment it is often impractical to lock the chain for
the duration of the browse.

      Typically, when an object is deleted, the component needs to
consider whether there are any browses in progress.  If so, it must
consider each of them and update any browse cursor that is pointing
at the deleted object.

      In a performance sensitive system where objects are frequently
being added and deleted such additional processing on the mainline
path can be unacceptable.

      The solution described below uses an algorithm which is
independent of objects being deleted from the global chain in between
'get next' requests.  Operations which delete objects don't need to
worry about browses being in progress.

      Since a multi-task environment exists, a suitable locking
mechanism is assumed when accessing the global chain.

      The main concept behind the algorithm is to make each browse
remember the objects that have been returned so far.  No browse
cursors are needed since the process always starts at the head of the
global chain.  An object on the global chain is only returned if it
cannot be found in the 'browse history'.  When an object is returned
it is added to the browse history.

      For example, suppose that the global chain consists of the
following objects.  At the start of the browse no objects have yet
been returned and the browse history is empty.

      The first 'get next' of the browse would start at the head of
the chain and return object A since it wasn't found in the browse
history.  Object A would then be added to the browse history.

      The second 'get next' of the browse would again start at the
head of the chain.  It would skip past object A since it is present
in the browse history.  Object B would then be returned.

      Suppose object B was then deleted.  If a browse cursor was
being used, the deletion would have incurred extra processing since
the cursor would have been pointing at object B.  Instead, the third
'get next' merely returns object E after again noticing that object A
has already...