Re: Proposal: Commit timestamp

On 1/26/2007 9:38 AM, Stephen Frost wrote:
> * Jan Wieck (JanWieck(at)Yahoo(dot)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(at)Yahoo(dot)com #