[cap-talk] How desirable / feasible is a persistent OCAP language?

James A. Donald jamesd at echeque.com
Tue Jul 22 21:04:43 CDT 2008

Toby Murray wrote:
 > In a system, like E, that supports only asynchronous
 > remote invocation, could you give an example of how
 > the distributed update problem could interact with E's
 > support for persistence, in which objects in a single
 > vat can be revived from an on-disk representation when
 > the vat is restarted?

To rephrase:  If you have durable objects, you will
store durable information in them, often information
that eventually comes to have substantial value.  When
some of that information is invalidated by events, while
the rest remains valuable, what do you do then?
Obviously you want to edit that information, and no
other, but this is not easy, since the human conception
what has changed may not have any very direct relation
to the internals of the object, nor is the object likely
to be easily editable.

Assume the state of an object on one machine has
dependencies on the state of another object on another
machine - that for the system to work correctly, one
machine's state embodies assumptions about another
machine's state.  As a result of software changes,
hardware changes, reorganizations of information driven
by storage limits, unforeseen bugs that have to be
corrected, and so forth some of these assumptions become
invalid.  It is difficult to remedy this except by
recreating all the objects from scratch at the same time
or in proper sequence, but if they are permanent
objects, they probably embody, or have come to embody, a
lot of information that is costly to recreate.

All information that represents or reflects assumptions
about the state of other nodes on the network has to be
separated out, and made self correcting or easy to
correct, which can be done, and should be done, but is
often hard to do.  All information in one node about
other nodes has to be in objects that are in some sense
transient or user editable.  It does not follow that all
objects need to be transient, but it does follow that if
some objects are not transient, it is easy to get into

If the primary purpose of one's durable objects is to
provide durable capabilities, an object on one node is
primarily about objects on other nodes, in which case it
is highly likely to embody assumptions about other
nodes, which is highly likely to get one into trouble.

One way of avoiding this problem is to put all the
relevant information in an editable file or set of
database records, and then recreate the relevant objects
from the file from time to time, which means the data is
durable, but is not embodied in durable objects, hence
easier to update - the classic examples of such storage
being the unix configuration file, and the windows
registry file.

More information about the cap-talk mailing list