Quite the contrary, it was pretty clear, direct and
informative. I've kept my mouth shut until now because I really don't
have anything to add yet. I suppose I'll have lots to say once I
start trying to apply what you're describing to our system though.
The main reason I'm speaking up now is to tell you DON'T STOP! I'm
not sure if you remember the brief conversation we had about this
topic a few months ago, but I've been dying for this information to go
public ever since! Tell me more!
I do have one question: Why is the distinction between
write-once and write many necessary? It seems to me that all you need
is a dirty bit within each instance, and if an object hasn't been
updated it needn't be saved, right? This probably kills the
bundle-as-one-object batch saves you spoke about, but would mean not
having to remember whether or not an object is write-once and thus any
changes would discarded. It would also mean that ANY object could be
not-saved/updated if it didn't need it. I see this as distinct from
whether or not it should be persistently stored. If I ask for a ref to
a persistent object that is already in the store, and during my run I
don't change it, I shouldn't have to save it at the end, right?
| 7) What is a "WriteOnceObject?" What are they for?
|
| "WriteOnceObject" is a class that can be used as a base class in many
| cases in place of PersistentObject. An instance of a class derived
| from WriteOnceObject is just a persistent object, that the programmer
| agrees to "update" only in a certain way (at a certain time). The
| easiest explanation of what they are and what they are for, comes from
| their heritage...
|
| The lifetime of a persistent object includes its construction in one
| process, its salvation at the end of this first process, its
| resurrection in a future process, its salvation at the end of that
| process, ... . After using persistent objects in this mode, we
| noticed that *some* classes of objects are actually only modified
| during the first process (i.e., in the process in which the objects
| are originally constructed). It also turned out (from examining
| profiles of run) that loading and saving object (into files) was a big
| expense. The obvious fix was to skip the saves in any process after
| the first process. We call such objects "WriteOnceObject"s because
| they are written to the persistent store exactly once. Note that the
| programmer has to generally agree to *not* change the objects in
| future process incarnations, as the changes will not be saved back
| into the persistent store (we currently don't go to the expense to
| monitor and validate the programmers adherence to this restriction).
|
| The bottom line is than that a WriteOnceObject is part of a
| performance optimization that is available to select classes of
| persistent objects.
|
| Once this optimization was isolated, additional implementations of
| WriteOnceObject were constructed to further reduce object storage and
| retrieval costs. For example, one of the "nicest" ones bundles
| together all WriteOnceObjects from the originating process in a single
| multi-object file. This reduces the number of file opens and closes,
| and again greatly increase performance (for this quick and dirty
| file-system based object store).
-------> Tommy.
"I am who I am who I am. Well, who am I?" -- Dave Matthews