Re: 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)