Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of ianboston@gmail.com
 designates 209.85.223.172 as permitted sender)
MIME-Version: 1.0
Sender: ianboston@gmail.com
In-Reply-To: <CD3005DE.3AE0C%mueller@adobe.com>
References: 
 <CAH=Gj-=fsvdKo3BUu6+1n6grY_OLN7m1vDNL7SmwZ_JrzAy2Tw@mail.gmail.com>
	<CD3005DE.3AE0C%mueller@adobe.com>
Date: Fri, 1 Feb 2013 06:47:58 +1100
Message-ID: 
 <CAH=Gj-m2OXjJ1ifaQfV5NOyitbBZgaMb+76MrAq-RWZ6me_hpA@mail.gmail.com>
Subject: Re: Concurrency Question
From: Ian Boston <ieb@tfd.co.uk>
To: oak-dev@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On 31 January 2013 21:36, Thomas Mueller <mueller@adobe.com> wrote:
> Hi,
>
>>fuzzy distributed
>>time signal (as used in Google Spanner)
>
>
> That's quite interesting actually: Google Spanner relies on cluster nodes
> having very accurate clocks (atomic clocks / GPS): "TrueTime"

Only for the masters and then only to tie geographically distributed
servers to the same concept of TrueTime. In the same datacenter I
think the algorithm relies on determining jitter between nodes and
masters can agree amongst themselves what TrueTime is.

However for those that can't put GPS clocks into distributed
datacenters, and have control over the quality of the low level
hardware the fuzz on TrueTime is going to be too large to be of use.

I was thinking a highly accurate timestamp with knowledge of the
jitter might help in conflict resolution at merge time.... but maybe
not.

Ian

>
> http://www.wired.com/wiredenterprise/2012/09/google-spanner/all/
> http://static.googleusercontent.com/external_content/untrusted_dlcp/researc
> h.google.com/en//archive/spanner-osdi2012.pdf
>
>
> Regards,
> Thomas
>