Browse Prior Art Database

Maintenance of duplicate databases (RFC0677) Disclosure Number: IPCOM000003727D
Original Publication Date: 1975-Jan-27
Included in the Prior Art Database: 2000-Sep-13
Document File: 8 page(s) / 21K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

P.R. Johnson: AUTHOR [+2]


There are a number of motivations for maintaining redundant, duplicate copies of databases in a distributed network environment. Two important motivations are:

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 14% of the total text.

Network Working Group Paul R. Johnson (BBN-TENEX)

RFC # 677 Robert H. Thomas (BBN-TENEX)

NIC # 31507 January 27, 1975

The Maintenance of Duplicate Databases


This RFC is a working paper on the problem of maintaining duplicated

databases in an ARPA-like network. It briefly discusses the general

duplicate database problem, and then outlines in some detail a solution

for a particular type of duplicate database. The concepts developed

here were used in the design of the User Identification Database for the

TIP user authentication and accounting system. We believe that these

concepts are generally applicable to distributed database problems.


There are a number of motivations for maintaining redundant,

duplicate copies of databases in a distributed network environment. Two

important motivations are:

- to increase reliability of data access.

The accessibility of critical data can be increased by redundantly

maintaining it. The database used for TIP login and accounting is

redundantly distributed to achieve highly reliable access.

- to insure efficiency of data access.

Data can be more quickly and efficiently accessed when it is "near"

the accessing process. A copy of the TIP user ID database is

maintained at each site supporting the TIP login service to insure

rapid, efficient access. (Reliability considerations dictate that

this database be redundantly maintained, and efficiency

considerations dictate that a copy be maintained at each

authentication site.)

The design of a system to maintain redundant, duplicate databases is

a challenging task because of the inherent communication delay between

copies of the database, as well as the real world constraints of system

crashes, operator error, communication channel failure, etc. This paper

discusses some of the problems we encountered in designing such a

system, and outlines a system design for maintaining a particular type

of database which solves those problems.

The Model

A system for supporting duplicate copies of a database can be

modeled by a group of independent database management processes (DBMPs)

each maintaining its own copy of the database. These processes

communicate with each other over network communication paths. Each DBMP

has complete control over its copy of the database. It handles all

accesses to and modifications of the database in response to requests

from other processes. Though the DBMPs act only upon requests, in the

following they will often be said to be actually causing or originating

the modifications.

An important design consideration is that the communication paths

between the DBMPs are subject to failures. Thus one DBMP may have its

interactions with other DBMPs interrupted and/or have to wait until

communication paths are re-established before it can communicate with

other DBMPs. An assumption made in this paper about the communication