[e-lang] Persistence in E

Toby Murray toby.murray at comlab.ox.ac.uk
Thu Dec 14 06:44:49 CST 2006


G'day e-lang,

Just wondering about the maturity of E's persistence. From what I can
gather, the current E implementation allows one to revive a vat which
will have the same identity as a previous incarnation, but none of the
old vat's objects are revived. Is that right?

Hence a revived vat starts out with exactly the same objects in
existence as a first-time vat, right?

I'm guessing the best approach for writing persistent distributed
applications at the moment is to map all local object state to file
including remote captp:// URIs. Then on startup, reconstruct the local
object graph from the state in the file before reconnecting remote
references using the captp:// URIs.

Obviously this will yield a different program structure than the ideal,
in which a revived vat just reconnects captp:// URIs in response to
finding all of its old remote references are now broken, using the same
logic as one would use to deal with (say) a network partition at
runtime. 

Are there any strategies that can be employed to try to reduce the delta
between the two program structures to enable code to easily take
advantage of object persistence, once its implemented, without requiring
too much change?

Given the above, the following question is a bit useless, however, is
the point of the timeMachine.addExit() function to register an near
object as a root of persistence and the point of timeMachine.save() to
persist all objects reachable from roots of persistence?

Cheers,
Toby



More information about the e-lang mailing list