I think we will have to agree to disagree on this one. If a user is
deleting an object (i.e. deleting a reference), or deleting a link to a
file, they intend to delete it. What difference should it make if it is the
last one or not? Nightly file backups aside, what possible decision would
they make, assuming they really meant to delete it, other than to keep the
thing around artificially without any reference/reason? If the 'Catalog
manager' removes the product from the catalog, meaning a sales clerk cannot
sell it anymore, should the web page designer, when removing the reference
to the product from the web page, be allowed to say that product should stay
around?
I'm probably in the minority on this one, since the Entity Bean spec clearly
requires that Entity Beans be explicitly removed. Pity.
Dave
David Brown
Systems Engineer
GemStone Systems Inc.
2010 Crow Canyon Place
Suite 100
San Ramon, CA 94583
760-510-2754
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
www.gemstone.com <http://www.gemstone.com>
-----Original Message-----
From: Ihab A Awad (CBC) [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, May 12, 1999 4:18 AM
To: [EMAIL PROTECTED]
Subject: Re: relational storage (was "Re: Granularity of
EJBObjects")
David,
Thank you for the enlightening comments. However ....
David Brown writes:
> ...
> An object based repository, like GemStone/J, if it has multi-user,
> distributed, disk-based garbage collection, can manage this
problem
> automatically. The product record will remain as long and only as
> long as there is a reference to it. This is a big requirement for
> reusable object models.
Imho, yes and no. Automatic GC alone is not enough to support all
the
"drag this item into the trash" or "keep this object no matter what"
semantics that a good object-oriented user interface may require. As
a
minimum, I want the GC algorithm to be accessible so that I can tell
the user whether a particular operation will blow away their
precious
object or just unlink it from somewhere.
Think of the Unix filesystem semantics. OODBMSs with automatic GC
behave like hard links ... the last call to unlink() blows away the
file. That is _not_ the API made available to non-root users;
rather,
they are given a simpler model where they can believe that "del
<file>" always blows away the file and symlinks are an "unreliable"
link to a file. And, at the API level, yes, there _is_ access to the
"GC algorithm" because stat() tells me the number of links to a
file.
Hope this isn't too off-topic, but it does relate to object modeling
for long-term persistent storage.
Regards,
Ihab
--
Ihab A Awad <[EMAIL PROTECTED]>
Computational Biology Centers, Academic Health Center,
University of Minnesota. http://www.cbc.umn.edu/~ihab/
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in
the body
of the message "signoff EJB-INTEREST". For general help, send email
to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
