[cap-talk] Styles of persistance

Rob Meijer capibara at xs4all.nl
Sat Apr 5 02:44:17 CDT 2008


On Sat, April 5, 2008 03:46, Bill Frantz wrote:

>>
>>How did KeyKOS/EROS handle code upgrades/bug fixing?  With system
>>lifetimes of years I'd expect it would be handled and the problem was
>>solved somehow, but I'm not sure how.  Or do you just sidestep the
>>problem by making the spacebank so basic that it functions more like
>>mmap (or whatever malloc uses these days) in unix systems.
>
> Let me start by saying how I think they should be handled, then
> I'll relate our experiences which lead me to this conclusion. I
> hope Jonathan will agree with these recommendations.
>
> In order of decreasing desirability:
>
> 1. Avoid long-lived objects. For example, instead of keeping an
> instance of a reusable compiler, build a new instance of a use-once
> compiler for each compile. The need to upgrade a short-lived object
> is much less acute than a long-lived one. Each time you start with
> a new instance, you can start, relatively painlessly, with a new
> version.
>
> 2. Build long-lived objects that can serialize their state, load a
> new version, and have that new version reload the serialized state.
> This approach is suitable if the delay introduced by the serialize
> - reload cycle is acceptable. There are two sub modes in this
> category:

I think I understand why you would say so, but I feel there is a
fundamental issue with respect to failure issues. For me the folowing
ordering would make more sense:

1) Where possible, avoid using capabilities that should survive
   transactions.
2) Avoid having to re-bootstrap by making 'transaction surviving capability'
   holding objects persistent.
3) Make 'transaction surviving capability' holding objects into factory like
   objects wherever possible.





More information about the cap-talk mailing list