A Summary of Project so far [Re: Kernel LISP - how low down can it go?] -Reply

[Ray Whitmer]

** High Priority **

>>> Henry G. Baker <hbaker@netcom.com> 05/22/97 12:54am >>>
>I have noted elsewhere that the problems of synchronization of threads
>and OODB synchronization and recovery are all quite similar.  In the
>case of OODB's, you have multiple users trying to access the same
>objects.  If the objects are functional, then they can be shared without
>any restrictions, while if they are mutable, then each user is building
>up a different view of what the OODB looks like.  At commit time, the
>multiple users lay their cards on the table, and the winner gets to
>commit, while the losers have to roll back.  Recovery is _exactly_ the
>same, except that in this case the process you are competing with is
>the recovery process itself.  From time to time (i.e., when the system
>crashes) the recovery process wakes up and wins the hand, and
>forces everyone else to roll back.

I am not up on any latest research or model used by OODB in this
respect, so I may be way off base, but the model seems incomplete.  It
seems to me that another significant model is that everyone wins,
creating incrementally-diverging versions of the object graph, and active
applications which process the objects are notified of the existence of
divergent versions that may (or may not) need to be reconciled.  This may
be easy or hard.  Or if the creator of the divergent version happens to still
be alive, it can choose to eliminate the version altogether, but usually
there will be some form of reconciliation.  Or it may be desireable to keep
divergent versions around indefinitely.  How this is generically handled
in-process between live threads is significant, I think.

This divergence can either happen in real time, or as copies of the
database circulate in parallel or are manipulated on isolated replicated
systems, or on a laptop which becomes disconnected, etc.  In many
cases, the divergence of versions greatly outlasts the lifetime of the
processes which produced them.

Ray Whitmer