Browse Prior Art Database

Application Transparent Method of Dividing A Monolithic Database Manager Process Model

IP.com Disclosure Number: IPCOM000105005D
Original Publication Date: 1993-Jun-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 2 page(s) / 102K

Publishing Venue

IBM

Related People

Hidalgo, DS: AUTHOR [+2]

Abstract

In the previous Database Manager releases, the database engine was linked into each application which needed access to a database. Part of the design objectives for the Database Manager Distributed Database System version 2.0 (DBM 2.0) included separation of the database engine into a process distinct from those running the applications. This objective was achieved with minimal impact to the application code.

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

Application Transparent Method of Dividing A Monolithic Database Manager Process Model

      In the previous Database Manager releases, the database engine
was linked into each application which needed access to a database.
Part of the design objectives for the Database Manager Distributed
Database System version 2.0 (DBM 2.0) included separation of the
database engine into a process distinct from those running the
applications.  This objective was achieved with minimal impact to the
application code.

    In the Database Manager Distributed Database System version 2.0,
there is a set of Database Agent processes which service the database
requests on behalf of the application programs.  Each DBM Agent
process may service requests from any of the applications at any
time.  The processes running the database engine (the Agents) are
completely separate and distinct from the processes running the
application code.

    Added complication in DBM 2.0 results from the separation of data
base application and database service agent into two distinct
processes.  The Application Programming Interface (API) calls which
previously resulted in an intraprocess function call to a database
engine function needed to be modified to use interprocess
communications mechanisms in DBM 2.0.  This had to be accomplished
without requiring the application calls to change so as to support
applications written for earlier DBM versions.

    The design to separate the database engine from the application
process invented for DBM 2.0 employs interprocess communications
using message queues and shared memory.  A layer of code was designed
to sit "beneath" the API code and route database requests between the
applica tion process and the database agent processes.  This code
layer is called the Application Support Library (ASL) and effectively
substitutes for the database engine in the application process.

    When an application makes an DBM 2.0 API call, the API layer
checks a global "registration" flag which is set if the application
has regis tered with the DBM system.  This flag is initially set to
FALSE and is part of a data structure which is compiled into the
ASL's global data area and is maintained by the ASL code exclusively.
If this flag is not set, the API code makes a call to the ASL layer
to "register" the application with the DBM system so that it may make
database requests.

    The function in the ASL which registers the application connects
to a common message queue available to all DBM applications.  A
message packet is placed on the queue indicating that the application
is running and wants to make database requests.  The ASL also creates
a reply queue  from which it will read the response to its
registration request.  The ASL grants access rights to the D...