Re: Proposal: Commit timestamp

On 1/27/2007 7:26 AM, Gregory Stark wrote:
> Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
>
>> 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.
>
> If you know all the timestamps in the system then you don't need timestamps at
> all, just use a counter that you increment by one each time.
>
> Isn't the whole reason people use timestamps is so that you don't have to
> depend on atomically knowing every timestamp in the system? So two
> transactions can commit simultaneously on different systems and use the
> timestamps to resolve conflicts later.

This assumes that you never lose contact to the cluster or if so,
instantly stop all update activity because you are at risk that the
counters diverge. This risk is much higher with a simple counter than
with a system clock that was in sync at the time of disconnect.

With all the disadvantages and the pain factor of an asynchronous
multimaster replication system comes one big advantage. You can continue
autonomously and let conflict resolution figure it out later.

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 #