More timestamps

Ok then, time for another update. Back in Oslo for a few weeks, bad weather and raining currently, should be good for my project work I guess.

I’ve read a bit about Lamport timestamps as I was asked to do, and concluded so far that in our setting, they’re not useful unfortunately. The reason for that is that it works by increasing the internal clock (counter) for every event in the process, e.g. change of a record, or addition of a new one. Messages to other processes contains the local clock value. In the cases where it’s a message from another process, and that clock is ahead of the local one, it fast-forwards its own clock to the other processes’ clock+1 and continues from there. There’s always at least one clock tick between events.

Since our system will only connect with the other process (server) when synchronizing, this is, as far as I can see, not very useful. With Lamports method, if x and y happens in different processes and that does not exchange messages, you can’t say x -> y, and y -> x. Actually nothing can be said about when the events happened or which event happened first. They are because of that regarded as concurrent events.

As far as I see currently, the best solution we have available at the moment is the one Julie suggested a while back. We keep track of changes on the different servers using the local clock. When we synchronize up to the parent, we try to figure out how much the clock has drifted since last synchronization, and then apply the drift-time to the records changed. Certainly not a perfect solution, with many pitfalls. I’m actually unsure at the current point in time if it’s worth it doing this drift-correction at all, since that means we’ll have to struggle with updating the child’s records too with the drift time to make sure we have identical records both places. Of course, the drift calculations could be taken care of as part of the synchronization communications protocol, figuring out the drift time before we actually capture and serialize the identified changes to the server. Also – who knows – which clock is drifting “in the wrong direction”? The server might be the one that had problems with its clock for all we know. I guess the theory is that the servers further up in the hierarchy are handled with more care and better hardware/internet-connections so that there are fewer problems and more frequent adjustments done against official timeservers. And fewer people changing time(-zone) settings just for the fun of it, giving us even internally inconsistent data.. I guess that’s a case where we could actually gain some advantage from a logical clock system, and I guess we’ll probably have that in reality with the planned history-tables. Ugh, there’s so many potential problems if you start digging…

If I’m wrong anywhere, I’d be very happy to receive some feedback either here or on mail – I’m sure I’ve missed a point somewhere..

~ by andersg on June 26, 2007.