Sun rejects orthogonal persistence for Java

Arturo Bejar arturo@woz.org
Thu, 16 Sep 1999 08:46:31 -0700


At 10:10 PM 9/15/99 -0700, Rob Jellinghaus wrote:
>Oh, goodness, now you've got me wondering if I even know what the right
>reasons *are*!  :-) 

There is one obvious showstopper, which is upgrade. Persistence is all
about the commitment to maintain the state associated to an object through
time. The problem with orthogonal persistence is that you comit to
preserving all the state in every single object in the system through time,
that is an awful lot of commitment when you look at your average running
system.

There are many other (resolvable) issues as we discovered, but this one
issue is the killer.

I had an interesting conversation about telephony the other day. They
handle upgrade by letting old processes run to completion while new process
start with the new code. But this has no way for state in an existing
process to roll over into a new one, unless you provide an interface to be
able to do that, and that interface (and the state that passes through it)
is in essence the real persistence/upgrade code.

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

Irrational (though perhaps justified) fear? ;-)

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

This actually breaks down in two cases:
1- The ability to to update object behaviour without having to update the
state. (Which proved to be very frequent once we got minimal state
persistence going)
2- The ability of new object definitions with new internal state to cope
with old state. 

When you reduce the set of objects/state that you are commiting to
maintain, 2 becomes a much more tractable problem. You pay the design cost
up front of deciding what state in your object you are commiting to
maintain, and if you are a good lazy programmer this will be relatively
little state.

>to my mind, schema evolution is
>the killer issue with orthogonal persistence at the language level.

Ayup.

...

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

All levels of bakosity are appreciated. I think that you have to make a
conscious decision of just exactly what it is you want to tell the future.
To choose what things would you put in your limited bag that will allow you
to reconstruct your life if your house burns down. All other state is
transient, any state you commit to preserving you will have to do so until
you decide not to anymore...

Arturo
______________________________________________________________________
Arturo Bejar               "Have we been here? Or are we yet to come?"
arturo@woz.org                      - Dr. Who (as played by Tom Baker)