Re: Proposal: Commit timestamp

On Sun, Feb 04, 2007 at 01:36:03PM -0500, Jan Wieck wrote:
> 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?

I'm wondering whether a combined approach is needed. This makes
things more complicated, but what if you somehow co-ordinate local
counters with shared clock ticks? When you get a failure on your
talk to the shared clock, you regard yourself as in some sort of
failure (you're going to need softfails and that sort of thing, and
yes, I'm flapping my hands in the air at the moment). At rejoin to
the cluster, you need some sort of way to publish "here's the counter
and the last global time I had" and "here's my current counter". You
can publish local time with this too, I guess, to solve for conflict
cases, but that seems like the sort of decision that needs to be
pushed down to policy level.

A

--
Andrew Sullivan | ajs(at)crankycanuck(dot)ca
The whole tendency of modern prose is away from concreteness.
--George Orwell