On 2/4/2007 10:53 AM, Theo Schlossnagle wrote:
> As the clock must be incremented clusterwide, the need for it to be
> insync with the system clock (on any or all of the systems) is
> obviated. In fact, as you can't guarantee the synchronicity means
> that it can be confusing -- one expects a time-based clock to be
> accurate to the time. A counter-based clock has no such expectations.
For the fourth time, the clock is in the mix to allow to continue during
a network outage. All your arguments seem to assume 100% network uptime.
There will be no clusterwide clock or clusterwide increment when you
lose connection. How does your idea cope with that?
Obviously the counters will immediately drift apart based on the
transaction load of the nodes as soon as the network goes down. And in
order to avoid this "clock" confusion and wrong expectation, you'd
rather have a system with such a simple, non-clock based counter and
accept that it starts behaving totally wonky when the cluster reconnects
after a network outage? I rather confuse a few people than having a last
update wins conflict resolution that basically rolls dice to determine
"last".
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
