Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!odi!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.databases
Subject: Re: Extended RDB vs OODB
Message-ID: <1989Aug21.195543.1463@odi.com>
Date: 21 Aug 89 19:55:43 GMT
References: <3560052@wdl1.UUCP> <411@odi.ODI.COM> <458@cimshop.UUCP> <2177@cadillac.CAD.MCC.COM> <20@dgis.daitc.mil> <2230@cadillac.CAD.MCC.COM> <3367@rtech.rtech.com> <DCMARTIN.89Aug17075703@lisp.eng.sun.com> <32@dgis.daitc.mil> <1989Aug18.140814.29371@odi.com> <35@
Reply-To: dlw@odi.com
Organization: Object Design, Inc.
Lines: 38
In-reply-to: jkrueger@dgis.daitc.mil's message of 18 Aug 89 21:06:24 GMT

In article <35@dgis.daitc.mil> jkrueger@dgis.daitc.mil (Jonathan Krueger) writes:

   That's interesting.  How does one build multiuser systems out of
   Symbolics computers?

Same as any other workstation.  You connect them on an Ethernet.  One
(at least) of the workstations is a Statice server, which has the disk
that holds the nonvolatile data itself.  The others act as clients,
retrieving and storing data via a network protocol built on TCP/IP.

   >Did someone give you the impression that proposed OODBMS systems do
   >not provide shared access to persistent data?

   Rather that no one gave me the impression that they did.  Do they?

Well, as I said, people use the term "OODBMS" to cover a wide range of
things.  Our product certainly does, and I strongly expect other
forthcoming OODBMS products to do so.  Statice already does, and so
does Servio-Logic's Gemstone.

   Would someone out there describe his production OODB and state how many
   concurrent users access it?  How many are actively updating it on a
   typical day?

You're looking for a benchmark, and a benchmark result.
Unfortunately, it's not easy; see my previous posting on the subject.
I can tell you that during debugging of Statice, we ran up to 140 or
so client workstations (mostly in Cambridge Mass and some in the Los
Angeles area), each accessing the single server about once every two
minutes to do a simple associative update transaction.  The server was
able to keep up with this.  We didn't try saturating the server with
transactions.  Each of these transactions was a true database
transaction, setting locks and forcing the log to disk and so on.
This doesn't prove anything about performance, of course, but it does
mean that I was serious when I said "shared access to persistent
data".

Daniel Weinreb		Object Design, Inc.		dlw@odi.com