Patrick Welche wrote:
All this sounds remarkably similar to the postgres-r database replicationThe issue is not when the two servers can talk -- that is easily solved with techniques such as two phase commit. The problem is when server A and B are not able to communicate and you want both of them to be able to continue taking updates yet build a consistent view of the database once they can communicate.
problem cf nice paper by Bettina Kemme
http://www.cs.mcgill.ca/~kemme/papers/vldb00.html
Here it would be client connects to imap server A and says "APPEND". Server A
then sends "APPEND" to server A and server B using a group communciation
protocol (cf spread) which guarantees the ordering of the commands. Server A
and server B then receive the APPEND and do it. If server B received an APPEND
at nearly the same time, that APPEND would still appear in the same place in
the input queue of both servers => the UID would come out the same. You still
have the hard problem of conflict resolution after network partitioning :(
--
John A. Tamplin Unix System Administrator
Emory University, School of Public Health +1 404/727-9931
