On 8/17/2004 1:30 PM, Christopher Browne wrote:

> Jeff Amiel <jamiel at istreamimaging.com> writes:
>> To that point, think about the complexities in dealing with merge conflicts.
>> Client A (offline) makes a change to record 12345
>> Client B (offline) makes a change to record 12345
>>
>> Merge takes place.
>> Who's change becomes effective?
>> Last man in the pool?  How do you let Client A know that his changes 
>> never became effective.?
> 
> Yes, that's the "standard" problem with multimaster replication.
> 
> With a PalmPilot, what happens is that the offending records get
> duplicated, and you get a note in the "sync log" telling you to fix
> the conflict.

Yeah, that's sufficient for data that is something you allways overwrite 
in your business process, like an address. Now think of this problem:

     Three accounts:
         1=  $600
         2=  $200
         3=  $400
       sum= $1200

     Node-A transfers $100 from account 1 to account 2

     Node-B transfers $200 from account 1 to account 3

     So Node-A wants to update
         account 1 = $500
         account 2 = $300

     while Node-B wants to update
         account 1 = $400
         account 3 = $600

Since there is no conflict on either account 2 or 3, those updates go 
through so we end up with $900 on those two. But which is the right 
value for account 1? It is neither $500 nor $400. It would be $300 ... 
but none of the nodes tries to set it to that value.

To solve this problem the balance field of accounts must be known to the 
replication system as balance field and not a new value but a delta 
value must be communicated. So you get down to a per column 
configuration need. And every node in the cluster must keep track of 
which updates it has applied, because doing the delta twice is as wrong 
as doing it never.


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #