Undo

Anders Vinberg (andersv@cai.com)
Fri, 20 Oct 1995 12:26:09 -0400


It is true that many other disciplines have worked on the
synchronization problem. In my own experience, we do something
similar in asynchronous replicated databases.

The basic idea is that distributed databases that synchronize
through two-phase commit protocols (just an implementation
technique for global locks) are a practical impossibility.
Say you want to update the price lists in all the branch
offices from the central database at hsadquarters. With
synchronized locks, the master tries to take locks, and if
San Diego is down for the moment it abandons tme attempt
and rolls back all the transactions. This doesn't match
business realities: you obviously want to update everybody
else and let San Diego find out about it when they get online.
This is what message queue-based transaction management does
in asynchronously replicated databases. Obviously, this raises
the possibility of conflicting transactions (at least if there
is more than one transaction origin, simple master-detail
systems can be easily handled).

There is no automatic way of handling conflict resolution.
In our system (CA-OpenIngres) you can select one of a set of
automatic resolution schemes if they match your semantics
(FIFO, LIFO, etc.), or you can write your own logic, or you
can raise an alert and ask a human for hslp with resolving
the conflict.

While some database systems make do with only generalized automatic
rssolution schemes, they generally impose severe restrictions
on the deployment configuration. In a completely general scheme,
with peer-to-peer update-anywhere capability, you *either* to
accept conflict resolution with possibly arbitrarily complicated
rollback schemes, *or* demand lock synchronization which is both
fragile and slow. Or so it seems to us.

While I agree that undo in a human-driven VR world might be
disconcerting, if we are going to do it we can probably learn
from other disciplines.

Anders Vinberg
Computer Associates
andersv@cai.com


  • Next message: PAUL: "Re: Multiple Rotations"
  • Previous message: Anders Vinberg: "News groups and mail archives"