how to detect conflict..

[jli125]

Hi,

We are building up an infrastructure based on Ice. one of the problem is to deal with disconnected operation. The idea is I want to bring disconnected replica back to consistency after a disconnected replica reconnects to the the group. Assume that there are several replicas (A,B,C) in the replica group, if A makes some changes, those changes should be multicasted to the rest in the group (jgroup does this for us). i.e B,C in the group should be updated. But if A is disconnected from the replica group, assume the situation that B,C make some changes online, and A makes some changes "offline" as well. After A reconnects to the group, the system should keep them consistent. for example, if i am making a share calender, it will be fine for A,B,C if they add or remove events on different dates, as A,B,C touch disjoint data regions. However the problem is that if A,B,C edit event on the same date, there must be some conflicts occured. My goal is to let our infrastructure to detect those kinds of conflicts, which means that developers only need to put minimal effort on resolving conflict problems or supporting disconnect operation for their applications based on our infrastructure.

I am thinking if there is a way to place all changes into some storage, volatile or persistent to keep track of changes. Like in my example, system can be in touch with two storages, after A reconnected to the replica group. One is for the disconnected replica A and the other one is for connected replcas B,C. Upon reconnecting, B.C will replay A's changes from A's storage, and A will replay B,C's changes from B,C's storage. But the problem is how the system knows what methods A or B or C operated and how to detect conflict...I dont know if my idea is doable or not, or there is any easier or possbile way to achieve my goal.....Can you guys help me out? thanks for your time!!!

p.s i am using Ice 3.1.1

kind regards

Jin

[michi]

A common way for doing this sort of thing is maintain an update count with each record that records the last update that was successfully mirrored by the peers. When peers lose connectivity and make off-line updates, they set a dirt bit on the record and, when they resume connectivity, compare the update counts of all records with the dirty bit set to detect a conflict.

Some scheme along those lines might help with what you are trying to do.

Cheers,

Michi.