Browse Prior Art Database

Optimal Selection of Dynamically Available Database Access Plans

IP.com Disclosure Number: IPCOM000107640D
Original Publication Date: 1992-Mar-01
Included in the Prior Art Database: 2005-Mar-22
Document File: 4 page(s) / 178K

Publishing Venue

IBM

Related People

Moore, RE: AUTHOR [+3]

Abstract

A mechanism is described for selecting among many small, non-exclusive database access plans in response to a particular database access request. Each plan can contain one or more program modules (classes), and more than one plan may contain the same program module.

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

Optimal Selection of Dynamically Available Database Access Plans

       A mechanism is described for selecting among many small,
non-exclusive database access plans in response to a particular
database access request.  Each plan can contain one or more program
modules (classes), and more than one plan may contain the same
program module.

      In an object-oriented programming system (OOPS), it is
necessary to interface with a non-volatile data store to support the
persistent storage of objects.  In order to fully provide the support
required by application classes, there must be base services to
support the creation, storage, and retrieval of these persistent
objects. These persistent objects are instantiated and manipulated in
memory for a period of time, but spend the majority of their
existence in the non-volatile database storage system.

      In order to communicate with some database systems, for
example, DB2*, the base services component must specify a database
access plan.  This database access plan, commonly called "plan" for
short, provides the linkage between the data areas of a class and the
database's application programming interfaces (APIs).  There may be
one plan for the entire application's OOPS environment, or there may
be many plans for the application.  When there are many plans, each
plan usually supports only a small portion of the total database
access requirements.  Dividing the plans into smaller, discrete
components provides a number of real advantages:
o  loading a smaller plan is quicker and requires less memory;
o  binding a smaller plan is quicker and impacts fewer users;
o  a smaller plan allows the packaging of separate products which may
reside on the same platform of base services; and
o  a smaller plan allows greater flexibility when implementing
changes.

      The figure demonstrates the relationship between database
access plans, class or program modules and unit of Work Instances. It
is easy to discern that there is no real correlation in their
grouping.

      The mechanism described herein allows one to develop a plan
selection mechanism which exhibits the following desirable
characteristics:
o  Minimizes the number of switch plan requests.
   Each time a database access is requested, it must be determined if
the class which has requested the database access is in the current
plan.  If it is not, then a switch to a new plan must be made.
However, switching plans require a significant amount of CPU
overhead.  This mechanism minimizes the total number of switch plans
so that system performance will not be compromised by unnecessary
plan switches.
o  Supports a Unit of Work commit to the database.
   To switch plans, the current plan must first be disconnected
before the new plan can be attached.  When a plan is disconnected,
any uncommitted database activity is rolled back. This causes some
very serious problems with Unit of Work mechanisms.
   If a Unit of W...