Sun rejects orthogonal persistence for Java

[Mark S. Miller]

At 08:52 AM 9/16/99 , shapj@us.ibm.com wrote:
> >i.e. you don't ever want to
> >tell the future you anything more than you have to about what you are doing
> >now, since what you are doing now is so very likely to be wrong.  Hmm,
> >temporal information hiding???
>
>I find this comment confusing. ...  I suspect that
>if there is an argument *against* persistence, it lies here.

It is indeed confusing until a clarification is made.  The argument is not 
against persistence, it is against orthogonal persistence -- sort 
of.  Actually, it is not *against* orthogonal persistence, it is against 
the argument that is normally made in favor of orthogonal persistence.  The 
normal argument is that it saves the programmer from writing redundant and 
error-prone manual saving logic.  Why write code to save state when you've 
already written code to represent that state in memory?  The answer is the 
upgrade problem:

The benefit of manually written persistence code is that it forced the 
programmer through the exercise of defining a data format for the 
persistent representation of his state that was different, and hopefully 
semantically much smaller, than the run-time representation of his 
state.  This is what I call the semantic funnel, and corresponds exactly to 
Rob's notion of temporal encapsulation.  Once this work is done somehow in 
order to deal with upgrade, orthogonal persistence cannot save us any 
coding or debugging time.  However, it may still be a performance win over 
invoking the manually written funnel code, or not, depending on the 
platform, for when we aren't actually upgrading -- by far the typical case.

In an EROS context, orthogonal persistence is still clearly motivated by 
performance, but the EROS programmer must be careful not to be seduced away 
from crafting a funnel.  On platforms such as un-augmented Java, where the 
only available persistence choice is serialization, reusing the funnel for 
persistence gives a huge performance *win*, so orthogonal persistence would 
only subtract value.

Since the following appeared in a different thread that may have been 
missed by those interested in persistence, I include my earlier:

>2) There are two necessary problems that non-orthogonal persistence 
>mechanisms (manually written "save" code) normally solve.  Fully 
>orthogonal persistence -- as in EROS and the persistence system I build at 
>Communities.com for Original-E -- only solve one.  The two problems are 
>having computation state (or a useful subset thereof) survive machine 
>failures (persistence per se), and having this state survive into a new 
>release of the program that it instantiates (the upgrade problem).
>
>After I almost killed us at Communities.com with a fully orthogonal 
>approach, in which upgrade was intractable, Arturo had the great insight 
>that I call the semantic funnel: the programmer must specify the small 
>subset of computation state that they are committing to support through 
>future upgrades.  This must be a deliberate and manual choice, however 
>much automatic support we provide to make it pleasant.  The programmer 
>must then, of course, figure out how to revive the rest of their 
>computation from this saved state.  Each mutually suspicious component of 
>a system must be able to restore in this manner without vulnerability to 
>the other components doing likewise.  The relationships among such 
>components must be restored as part of this process.
>
>We have to have this logic for supporting upgrade, even if we were 
>operating only on EROS.  However, when on EROS we would plausibly use this 
>logic *only* for upgrade, whereas on other platforms we'd use it for both 
>persistence and upgrade.  EROS therefore won't save us any code, but it 
>will allow our persistence to be higher fidelity and higher performance.


-----------------------------------------------------------
Due to a bug (possibly at my ISP, but probably in Eudora 4.2.0.58), on 9/15
I lost 18 email messages.  If it's possible for you to check whether you
sent me something on that date, resending it would be great.  Otherwise,
please excuse my non-responsiveness to email you may have sent around that
time.  Sorry for the inconvenience, and thanks.

         --MarkM