Re: Proposal: Commit timestamp

On 1/26/2007 9:38 AM, Stephen Frost wrote:
> * Jan Wieck (JanWieck@Yahoo.com) wrote:
>> On 1/26/2007 2:37 AM, Naz Gassiep wrote:
>> >I would be *very* concerned that system time is not a guaranteed 
>> >monotonic entity. Surely a counter or other internally managed mechanism 
>> >would be a better solution.
>> 
>> Such a counter has only "local" relevance. How do you plan to compare 
>> the two separate counters on different machines to tell which 
>> transaction happened last?
> 
> I'd also suggest you look into Lamport timestamps...  Trusting the
> system clock just isn't practical, even with NTP.  I've developed
> (albeit relatively small) systems using Lamport timestamps and would be
> happy to talk about it offlist.  I've probably got some code I could
> share as well.

I think the system I described is a slightly modified Lamport generator. 
The maximum timestamp of any row updated in this transaction, you can 
consider that the "counters received from other nodes". Then I make sure 
that the next counter (timestamp) is higher than anything I know so far, 
and I add cluster-wide unique tie breaker to that.

Looking closer, I don't even have to check the timestamps of the rows 
updated. Since a remote transaction replicated will bump the local 
Lamport clock on commit, a local transaction modifying such a row will 
have a timestamp in the future of that remote transaction, even if my 
local clock is limping behind.


Jan

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