bership has changed since the last time it was accessed.

As a result, an algorithm attempting a complex calcu-

lation may get a somewhat unstable picture. Imagine

attempting to converge on an iterative solution while the

variables are being randomly changedt Imagine at-

tempting to carry out a trial balance while someone is

still posting transactions to the accounts! Imagine two

concurrent jobs in an airline reservations system trying

to sell the last seat on a flightt

One's first reaction is that this shared access is

nonsense and should be forgotten. However, the pres-

sures to use shared access are tremendous. The proces-

sors available today and in the foreseeable future are

expected to be much faster than are the available direct

access storage devices. Furthermore, even if the speed

of storage devices were to catch up with that of the

processors, two more problems would maintain the

pressure for successful shared access. The first is the

trend toward the integration of many single purpose

files into a few integrated databases; the second is the

trend toward interactive processing where the processor

can only advance a job as fast as the manually created

input messages allow. Without shared access, the entire

database would be locked up until a batch program or

transaction and its human interaction had terminated.

The performance of today's direct access storage

devices is greatly affected by patterns of usage. Per-

formance is quite slow if the usage is an alternating

pattern of: access, process, access, process, ..., where

each access depends upon the interpretation of the

prior one. When many independent accesses are gen-

erated through multiprogramming, they can often be

executed in parallel because they are directed toward

different storage devices. Furthermore, when there is a

queue of requests for access to the same device, the

transfer capacity for that device can actually be in-

creased through seek and latency reduction techniques.

This potential for enhancing throughput is the ultimate

pressure for shared access.

Of the two main functions of database management,

inquiry and update, only update creates a potential

problem in shared access. An unlimited number of jobs

can extract data simultaneously from a database with-

out trouble. However, once a single job begins to up-

date the database, a potential for trouble exists. The

processing of a transaction may require the updating of

only a few records out of the thousands or possibly

millions of records within a database. On that basis,

hundreds of jobs could be processing transactions con-

currently and actually have no collisions. However, the

time will come when two jobs will want to process the

same record simultaneously.

The two basic causes of trouble in shared access are

interference and contamination.

Interference

is defined

as the negative effect of the updating activity of one job

upon the results of another. The example 1 have given

of one job running an accounting trial balance while

another was posting transactions illustrates the inter-

ference problem. When a job has been interfered with,

it must be aborted and restarted to give it another

opportunity to develop the correct output. Any output

of the prior execution must also be removed because

new output will be created.

Contamination

is defined as

the negative effect upon a job which results from a com-

bination of two events: when another job has aborted

and when its output (i.e. changes to the database or

messages sent) has already been read by the first job.

The aborted job and its output will be removed from the

system. Moreover, the jobs contaminated by the output

of the aborted job must also be aborted and restarted so

that they can operate with correct input data.

A critical question in designing solutions to the

shared access problem is the extent of visibility that the

application programmer should have. The Weyer-

haeuser Company's shared access version of I-D-S was

designed on the premise that the programmer should

not be aware of shared access problems. That system

automatically blocks each record updated and every

message sent by a job until that job terminates nor-

mally, thus eliminating the contamination problem en-

tirely. One side effect of this dynamic blocking of

records is that a deadlock situation can be created when

two or more jobs each want to wait for the other to

unblock a desired record. Upon detecting a deadlock

situation, the I-D-S database system responds by abort-

ing the job that created the deadlock situation, by re-

storing the records updated by that job, and by making

those records available to the jobs waiting. The aborted

job, itself, is subsequently restarted.

Do these deadlock situations really exist? The last I

heard, about 10 percent of all jobs started in Weyer-

haeuser's transaction-oriented system had to be aborted

for deadlock. Approximately 100 jobs per hour were

aborted and restarted! Is this terrible? Is this too

inefficient? These questions are hard to answer because

our standards of efficiency in this area are not clearly

defined. Furthermore, the results are application-de-

pendent. The Weyerhaeuser I-D-S system is 90 percent

efficient in terms of jobs successfully completed. How-

ever, the real questions are:

--Would the avoidance of shared access have per-

mitted more or fewer jobs to be completed each hour?

--Would some other strategy based upon the detecting

rather than avoiding contamination have been more

efficient?

--Would making the programmer aware of shared

access permit him to program around the problem and

thus raise the efficiency?

All these questions are beginning to impinge on the

programmer as navigator and on the people who design

and implement his navigational aids.

My proposition today is that it is time for the appli-

cation programmer to abandon the memory-centered

view, and to accept the challenge and opportunity of

navigation within an n-dimensional data space. The

software systems needed to support such capabilities

657

Communications November 1973

of Volume 16