Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!gatech!hubcap!billwolf%hazel.cs.clemson.edu
From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 )
Newsgroups: comp.sw.components
Subject: Re: Real-time Garbage Collection
Message-ID: <6587@hubcap.clemson.edu>
Date: 26 Sep 89 17:59:31 GMT
References: <910@scaup.cl.cam.ac.uk>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 29

From scc@cl.cam.ac.uk (Stephen Crawley):
>> ... unless the database replies that the object has been destroyed, 
>> in which case the identification number expires as well.
> 
> From the user's point of view, this is unacceptable behaviour by the
> application / database cabal.  

    The model involves a database which stores objects which can be
    created, destroyed, read, and written by various users.  The users
    might be partitioned into different groups (e.g., those authorized
    to destroy vs. those who cannot).  Now from the perspective of a
    user who can read and write but not destroy, the object's lifetime
    is potentially infinite, depending upon the whims of those who have
    the power to destroy.  By revalidating the identification number,
    such users receive continued assurances that the object still exists.

    If the object is destroyed, the identification numbers will then all
    expire automatically, regardless of how widely they were distributed.
 
> Bill replies:
>> We are managing objects in this way because they present worst-case
>> properties which do not permit us to use more efficient techniques.
> 
> What about garbage collection???  

    Won't work under the conditions I described (distributed environment).


    Bill Wolfe, wtwolfe@hubcap.clemson.edu