Sun rejects orthogonal persistence for Java

[Mark S. Miller]

Jonathan Shapiro wrote:
> >Persistence gives a form of recoverability.  The main problem with it 
> lies in
> >the difficulties that arise when two independently persistent systems must
> >interact.  This requires transactions, which in practice requires
>violating the
> >persistence model so that the transaction log will not be lost.  I suspect
>that
> >if there is an argument *against* persistence, it lies here.

At 10:38 AM 9/16/99 , Rob Jellinghaus wrote:
>That may well be, but it's a separate argument altogether :-)  And again,
>I'm looking specifically at the language level here.  Oops, maybe it's the
>same argument after all, in that an evolving system *is* in some sense two
>separate systems--its prior version, and its subsequent version....

Very good you two.  There is indeed a strong relationship, although 
transactions are not quite the right concept, and the argument is not 
against persistence, but for splitting our normal notion of 
reliable/invokable pointer/capability into two parts.  Two VATs are 
precisely the kind of interacting separately-persistent system Jonathan 
refers to.  Our solution is a symmetric generalization of the approach of 
the KeyKOS device key.  We have two kinds of interVAT pointer, both of 
which have capability security nature.

1) The live reference, which is fail-stop rather than reliable.  You can 
asynchronously ("<-") invoke on a live reference, but it may become 
disconnected (smashed) at any time.  Until it's smashed, it delivers all 
messages reliably & in order.  Any interVAT time trauma will smash all 
interVAT live references.

2) The SturdyRef, which remains connected across such time-traumas, but 
which cannot be invoked on.  You can ask a SturdyRef for a new live 
reference, and this latter will remain live only until the next time trauma.

This also recovers a necessary explicitness we were in danger of losing in 
moving to pure object/capability systems -- the recovery of distributed 
consistency following such a time trauma.  In order for a program to 
recover, the above abstractions encourage the programmer to think through 
very different recovery logic than the normal operational logic.  The 
result is transaction-like, but not transactional.  You can think of it as 
an unbundling of key elements of the transaction idea.


The relationship to upgrade?  If on upgrade we throw away the 
inter-"program" messages (where a "program" is a separately written 
upgradable subsystem), then we have a similar inter-program time trauma 
problem (insight also due to Arturo).  Putting it all together, I suspect 
that the boundaries in E between separately upgradable subsystems must also 
be VAT boundaries, so that we can successfully reuse the consistency 
recovery logic.  This is unfortunate.


-----------------------------------------------------------
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