Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ernie.Berkeley.EDU!jas
From: jas@ernie.Berkeley.EDU (Jim Shankland)
Newsgroups: comp.databases
Subject: Shared Memory (was Re: Ingres User's Association Meeting)
Message-ID: <29092@ucbvax.BERKELEY.EDU>
Date: 7 May 89 21:00:50 GMT
References: <3082@tank.uchicago.edu> <509@daitc.daitc.mil>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: jas@ernie.Berkeley.EDU (Jim Shankland)
Distribution: usa
Organization: University of California, Berkeley
Lines: 37

In article <509@daitc.daitc.mil> jkrueger@daitc.daitc.mil (Jonathan Krueger) writes:
>Look, would you care to research different methods of ensuring
>atomicity and serializability, support for them in commercially
>available operating systems, and their tradeoffs in performance,
>development, installation, scalability, portability, multiprocessor
>support?  If some technically qualified person (which I am not, by the
>way) were to post a summary on this topic, we'd all be most grateful.

That would be quite a summary :-).  Lots of open research issues
here.  Just a quick thought or two:  a DBMS designed around shared
memory is unlikely to make good use of a set of loosely coupled
processors such as a set of workstations connected by an Ethernet.
Sure, you can punt and run front-ends on diskless Suns, and have
them talk to a DBMS server on your big fileserver Sun (or Pyramid,
or Sequent, or ...).  But you're missing the opportunity to spread
your disks around the network, and gain both performance (through
I/O parallelism) and reliability (through redundancy), as well as making
good use of the, say, 75-1000 aggregate MIPS and 100-1000 Meg of RAM
on the network.

One answer to that problem:  run a DBMS server on each diskful workstation,
and implement a distributed DBMS on top of them.  That's RTI's
INGRES/STAR approach, I think.  There are persuasive arguments both
for and against this approach.  We live in interesting times.

As long as a server is running on a single machine, building it
around shared memory is a big win.  Note that non-availability of
shared memory on UNIX is rapidly becoming a non-issue:  the commercial
ports of Berklix all seem to have it; System V, of course, has it;
and 4.4bsd will have it.  In this context, cs_bob's assertion that
relying on shared memory was a major architectural design error on
RTI's part seems questionable, at best.

Jim Shankland
jas@ernie.berkeley.edu

"Blame it on the lies that killed us, blame it on the truth that ran us down"