> take a simple server setup. 3 servers, A, B & C. each peers with the others.
>
> server A gets a correct entry for a CD, server B gets an incorrect entry.
> Server C pulls from server B first. Now server B & C have the incorrect entry.
> Server A pulls from B, sees the conflict, throws it in the conflict bin to
> deal with later. Then it pulls from C and checks the conflict bin. It sees
> that there are more servers that have the other record, and replaces it's
> correct entry, with the incorrect one.
Good analysis -- but I don't think that is necessarily a problem. Let
me continue your scenario:
A user on server A sees the incorrect entry and corrects it. Server B
pulls from Server A and detects a conflict between the corrected record
and the incorrect record in the DB. Server B tosses the new record into
the conflict bin. Another user on server C makes the same correction.
Server B pulls from server C, and now has two of the same records in
the conflict bin, and therefore accepts the record into the DB. The
last sequence could also occur on server B: a user makes the correction
and the server now finds the record in the conflict bin and the
corrected record and accepts it into the DB.
This algorithm is based on the idea that if something gets entered
wrong in the first place, that data will likely propogate through the
system as you identified. However, as people look at the wrong entries
they will enter corrections, and as more corrections float about the
data will eventually settle on the most common spelling.
> And no matter what we choose, I'd suggest that each server have at least
> 2 peers. 1 peer servers run the risk of being orphans.
I don't see what you mean by that. Can you please elaborate?
--ruaok Freezerburn! All else is only icing. -- Soul Coughing
Robert Kaye -- robert nospam at moon.eorbit.net http://moon.eorbit.net/~robert