hongy@ifi.uio.no (Hong Ye) writes:

>I am currently reading about ASK INGRES/Replicator. I cannot understand how the
>conflict resolver works. How does it control the concurrency of transactions
>and consistence of replicas? If updates to two replicas of the same data item
>in two different sites occur simultaneously, will one of the updates be lost?
>or is roll back caused in one of the sites? How about the transactions which 
>have read the update being rolled back? should these transactions be rolled
>back too?

If two people update the "same" piece of data at two sites at the "same"
time, then both updates will commit successfully.  The updates will then
be propagated to other sites by the replication server as part of a new 
transaction.  This happens after the original transactions have committed,
at a configurable time (as soon as possible, fixed interval, etc.).  For
this transaction (which uses 2PC) you can configure the appropriate conflict
resolution, either none, date/time stamped or "priority" ordered.  If there
is no automatic resolution, the conflict is logged and will require manual
intervention to fix.

While the conflict exists in the system, other transactions may read
"incorrect" data.  These transactions will complete regardless of any
collision resolution.

If you plan to use Replicator, you need to design your database to avoid any
problems due to update collisions.  This requires a little thought, but in
most situations where Replicator is useful the problems can be solved fairly
easily.  If there are more than a few conflicts requiring manual resolution
each day, your DBAs are going to be *very* busy!

-Mike Glendinning, Sequent UK (mikeg@sequent.com).

Ingres Q & A

To William's Home Page

© William Yuan 2000

Email William