Persistance
Laurent Martelli
martelli@iie.cnam.fr
27 Oct 1999 19:02:45 +0200
>>>>> "Thomas" == Thomas M Farrelly <tmfarrelly@hotmail.com> writes:
Thomas> users need a save button?
[...]
Thomas> The real reason for my comment on the presistance discussion
Thomas> was to see if there was a common agreement on wheter
Thomas> explisit copying was adequate to express _any_ of these
Thomas> persistance mechanisms.
Thomas> And that explisit save was a silly idea:)
Hmmm... What's persistence anyway ?
In Tunes glossary, we have this :
«An object is said to persist or to be persistent if it
consistently preserves its informational content accross some
expectable stressing modification, and more generally accross all
the modifications that time is likely to bring.»
But shouldn't we talk about the fact that the object still exists
after a shutdown ? A user of the system manipulates objects which he
identifies with an ID. And he expects that the same ID will always
refer to the same object. Therefore, I think that persistence is just
a matter of allowing the user to say which objects he wants to be
"persistent". He could choose between several policies :
1. objects are persistent by default; you must explicitly say
that you don't need an object anymore.
2. objects are not peristent by default; you must explicitly
say that you want to be able to refer to an object later.
This is in fact the conclusion that I reached after raising the issue
about OIL.
None of the policies seems to be better than the other. With the first
one, you have to do gc by hand from times to times otherwise you'll
run out of memory. With the second one, you have to explicitly make
objects persistent all the time, which is unconvenient too. Maybe we
can bet that we can increase the amount of available physical memory
faster than we use it. And thus prefer policy 1. But we should be able
to choose.
Is there a consensus on this point ?
--
Laurent Martelli
martelli@iie.cnam.fr