Re: Sun rejects orthogonal persistence for Java shapj@us.ibm.com
Thu, 16 Sep 1999 11:52:24 -0400

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

Rob:

I find this comment confusing. Computation is causal, in the sense that the effects of prior computation are visible to subsequent computation. This is even true in systems that roll back -- we may abandon one of the causal universes, but as long as it exists the preceding computation is visible.

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.

Jonathan S. Shapiro, Ph. D.
IBM T.J. Watson Research Center
Email: shapj@us.ibm.com
Phone: +1 914 784 7085 (Tieline: 863)
Fax: +1 914 784 7595

"Marc Stiegler" <marcs@skyhunter.com>@eros-os.org on 09/16/99 11:15:07 AM

Please respond to "Marc Stiegler" <marcs@skyhunter.com>

Sent by: owner-e-lang@eros-os.org

To: "Rob Jellinghaus" <robj@unrealities.com>, "Mark S. Miller"

<markm@caplet.com>
cc: <arturo@woz.org>, <e-lang@eros-os.org> Subject: Re: Sun rejects orthogonal persistence for Java

Temporal information hiding. Half baked or not, I like that a lot. So the term "transient", for example, is analogous to the term "private", but across time. Personally, I had never thought about it that way. Indeed, having this as a conceptualization of the problem makes me feel closer to understanding the problem and developing the right set of tools for solving it, even though I am not at all likely to be the guy to actually try to solve it :-) This could turn out to be an example of a situation in which, buy carefully characterizing the reasons why something is impossible, the solution becomes evident :-)

--marcs

-----Original Message-----
From: Rob Jellinghaus <robj@unrealities.com> To: Mark S. Miller <markm@caplet.com>
Cc: e-lang@eros-os.org <e-lang@eros-os.org>; arturo@woz.org <arturo@woz.org> Date: Wednesday, September 15, 1999 10:08 PM Subject: Re: Sun rejects orthogonal persistence for Java

>At 09:41 PM 9/15/1999 -0700, Mark S. Miller wrote:
>>>>http://java.sun.com/aboutJava/communityprocess/jsr.html
>>>>
>>>>Look down the list for proposal JSR-000020. It's the one proposal in
the
>>>>list which was not ACCEPTED. Hmm, wonder why?????
>>>
>>>Actually, I still wonder why. Do you have any reason to believe they
>>>rejected this for the right reasons?
>
>Oh, goodness, now you've got me wondering if I even know what the right
>reasons *are*! :-) Seriously, I have no idea why they rejected it. They
>don't say, which is disappointing. What would be the *wrong* reasons to
>reject it?
>
>I know how much trouble we ran into at EC with trying to do rapid code
>development without practical tools for updating persistent instances in
>tandem with changes to their classes' code; to my mind, schema evolution is
>the killer issue with orthogonal persistence at the language level.
>
>I am now looking at the papers down near the bottom of
>http://www.sunlabs.com/research/forest/com.sun.labs.pjw3.main.html
>which talk about practical experience handling code updates in persistent
>Java object stores... don't yet know what they've come up with. (At a
>glance, not much.)
>
>This begs the question of whether orthogonal persistence at the language
>level is *conceptually* wrong, by some nebulous argument relating to
>information hiding from your future self... 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??? This concept just occurred to me, so please
>pardon its half-bakedness.
>
>Cheers,
>Rob
>
>