Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!mcsun!corton!inria!seti!motown!mark From: mark@motown.altair.fr (Mark James) Newsgroups: comp.object Subject: Re: Looking for explanation of OODB problem Message-ID: <2269@seti.inria.fr> Date: 10 Jun 91 13:17:52 GMT References: <1991Jun6.194440.2879@apd.mentorg.com> Sender: news@seti.inria.fr Organization: O2 Technology, INRIA/Rocquencourt, France Lines: 69 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. You're not the only one. >From "UNIX Today!", May 13, 1991, pp. 58, 64... > > [Paraphrasing: Dan Gerson, Xerox PARC, [...] > He's using a Sybase DBMS and is investigating > ObjectStore from Object Design.] > >[...] > > But OODBMSes have their drawbacks as well. "Currently, OODBMSes > are not very well developed," he [Gerson] says. > > "The basic problem in an OODBMS is in the user I/O inside of a > transaction," Gerson adds. >[...] > 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." In an OODBMS, the system gives you the *identity* of the object. Whether you see the data value encapsulated in the object depends on the level of encapsulation of the object. The value (if you can see it) may or may not be "some sort of copy"; this is entirely an implementation decision. I don't understand why Gerson generalizes about OODBMSes, since he has only investigated one of them. > Gerson syas he believes few people are aware of this fundamental > flaw in OODBMS technology because so few systems are out there. Or else, if Unix Today correctly presents his level of understanding, because there is no problem. > 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. Again, Gerson should not generalize from a sample of one; here, he sounds like a marketing guy trying to bad-mouth the competition. I can't speak for OODBMSes other than O2, but O2 resolves multiuser concurrency control problems with a classic two-phase locking mechanism. There is *nothing* inherent in object-oriented databases that inhibits this solution. The implementation of two-phase locking for long transactions involving complex and multimedia objects is not trivial, so perhaps his statement about "some vendors" is correct; but to conclude from that that transaction management is "the basic problem in an OODBMS" is just talking out of the top of his head. (Again, assuming that Unix Today has quoted him accurately.) Usual disclaimer: I'm speaking for myself here, not for my company. -- Mark James or O2 Technology [formerly Altair] Mail: B P 105 -- 78153 Le Chesnay -- France Telephone +33 (1) 39 63 53 93 Fax +33 (1) 39 63 58 90