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

Jonathan S. Shapiro shap at eros-os.com
Wed Jul 23 09:29:00 CDT 2008

On Wed, 2008-07-23 at 10:23 -0400, Sandro Magi wrote:
> So in summary, the crux of the matter is that making assumptions about 
> other machines is harmful in a distributed system, not that 
> durable/persistent objects in and of themselves are harmful. I think I 
> agree with that phrasing, but not the stronger assertion that durable 
> objects themselves are to be avoided at all costs.

This is why MarkM put so much time and thought into the whole
ref/SturdyRef/BrokenRef stuff in E.

But it is definitely the case that recovery can cascade unless your
program is designed otherwise, and designing to avoid rollback cascade
involves accepting either (1) a very loose definition of "consistency"
within the distributed application, or (2) a qualitatively harder data
schema and associated applications that cope with partial consistency by
making it explicit.

Neither solution seems attractive, which is why, with the exception of
things that can be dispatched in fully encapsulated sub-computations
dataflow-style, real programmers simply bet that failures are unlikely
enough to be ignorable. Dealing with the issues is just too bloody hard.


More information about the cap-talk mailing list