Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!zephyr.ens.tek.com!tektronix!percy!m2xenix!servio!marcs
From: marcs@slc.com (Marc San Soucie)
Newsgroups: comp.object
Subject: Re: Looking for explanation of OODB problem
Message-ID: <1991Jun17.171444.4809@slc.com>
Date: 17 Jun 91 17:14:44 GMT
References: <1991Jun6.194440.2879@apd.mentorg.com> <1991Jun10.070451.18516@chinet.chi.il.us> <1991Jun13.231646.29226@odi.com>
Organization: Servio Corporation
Lines: 89


> >From "UNIX Today!", May 13, 1991, pp. 58, 64...
>
>     [Paraphrasing: Dan Gerson, Xerox PARC, is developing collaborative
>     systems, in particular a document database that will allow
>     multiple users and track versions. He's not sure OODBs are best
>     for his work. He's using a Sybase DBMS and is investigating
>     ObjectStore from Object Design.]
>
>     During a transaction in an OODBMS, objects are loaded into memory,
>     either real or virtual. "As soon as you execute a transaction, you
>     can't see the object anymore," he says. "In an RDBMS, the system
>     is giving you some sort of a copy. In an OODBMS, the system is
>     giving you the actual object, so they're only valid in a
>     transaction."
>
>     Gerson syas he believes few people are aware of this fundamental
>     flaw in OODBMS technology because so few systems are out there.
>     Those that are function as single-user, workstation-based
>     development systems, not multiuser systems where deadlocks can
>     occur. Besides, he says, he thinks some OODBMS vendors are either
>     unaware of the possible problem or deliberately ignoreing it.

The above discussion describes only ONE possible implementation of semantics
for accessing shared objects in an OODBMS. If you research the available OODBMS
products, you will find some that were designed as multiuser systems. For
example, in GemStone the following semantics are provided.

Case 1) Let's consider an object X. The system gives you a stable view of X
during your transaction. The object is presented as it existed at the start of
your transaction. Any changes you make to object X during your transaction are
visibile to you but not to other sessions (i.e. not to other users running
other transactions). At the point you "commit" your transaction, your changes
to X become visible to other transactions which start after your "commit". The
"commit" does not destroy your view of object X; you still have visibility of
the state of the object as it was committed. This example assumes that there
were no conflicts on object X.

Case 2) Now let's consider the case where two transactions A and B are both
trying to change object X. Assume A and B begin at the same time, and thus see
the same state of X. If the application chooses to use pessimistic concurrency
control, both A and B will attempt to lock X for writing; one transaction will
be granted a lock, the other will be denied the lock. Assume A was granted the
lock; it will proceed as in Case 1 above. Transaction B still has a stable view
of X that is unaffected by the transaction A. If B wants to see the new state
of X that was committed by A, B must abort its transaction.

In cases 1 and 2, I have described the semantics of objects seen by methods
written in the OPAL persistent database language used by GemStone. GemStone
also provides application program interfaces for C, C++, and Smalltalk. With
these API's it is possible to COPY the contents of an object into a
user-interface program, if it is desired to have a copy of an object displayed
that is independent of any transaction states.


From Hal Render:

> One thing that the relational treatment of updates (i.e. copy the data
> to be changed and don't write it back to the database until the transaction
> is completed) gave you is a focus around which to base mechanisms for
> handling concurrent access and undoing erroneous updates. I don't
> think that there is anything inherent to OODBMSs that prevent similar
> facilities from being incorporated, but it is possible that current
> implementations do not address the topic very well yet. Not having the bucks
> to spend on a non-research OODBMS, I haven't had the chance to get any first
> had experience.

Note that GemStone provides a virtual copy of any objects accessed by a
transaction. Changes made to those objects are not written to the permanent
database until the transaction commits. Commit is an atomic operation. Either
all of the modified objects become part of the permanent database, or none of
them do. Appropriate algorithms are used to ensure that commit is atomic in the
presence of possible power failure or system crash, etc.

The GemStone API's and OPAL language each have functions and methods that may
be executed to cause a commit. The application is in control of when a commit
happens.

With regard to changes to an object being visible in displayed output, that
problem is in the domain of the display system. Often the display system is a
form or graphics-based application where user actions (mouse, keyboard) change
the displayed information, and the database objects are then modified by the
application software to reflect the changes to the display.


    Allen Otis
    Servio Corporation
    Beaverton, Oregon
    otisa@slc.com