Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!ncar!csn!boulder!happy.colorado.edu!hsrender
From: hsrender@happy.colorado.edu
Newsgroups: comp.object
Subject: Re: Looking for explanation of OODB problem
Message-ID: <1991Jun8.114630.1@happy.colorado.edu>
Date: 8 Jun 91 17:46:30 GMT
References: <1991Jun6.194440.2879@apd.mentorg.com>
Sender: news@colorado.edu (The Daily Planet)
Followup-To: comp.object
Organization: University of Colorado, Boulder
Lines: 32
Nntp-Posting-Host: happy

In article <1991Jun6.194440.2879@apd.mentorg.com>, plogan@apd.mentorg.com (Patrick Logan) writes:
> It is not entirely clear what is being described below. Rather than
> propose my interpretation, I am looking for other opinions and
> experiences.
> [description of problem deleted]

It *sounds* like what he is describing is an update problem.  For example,
if I retrieve an object, display it on the screen, and then make a change
to the object, I have two concerns: 1) will my change be automatically 
propagated to the database or is there a "commit point" sometime down the
road; 2) will my change be reflected in the displayed image of the object
(presuming you didn't make the change directly through the display).  In
the first case, it is a problem when to recognize the end of a transaction
and commit the changed objects.  Since the notion of transaction is not
commonly considered within OO programming systems, it will have to be addressed
as a new element of OODBMSs.  In the second case (view update), this is a
regular part of an OO system with displayed output, namely, how often do I
synchronize the displayed image of an object and the object itself.  I think
the two cases are analogous, at least when considered from the perspective
of the old Model-View-Controller framework.

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.

hal.