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 jukka.zitting@gmail.com
 designates 209.85.214.169 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <528B79FD.8030809@douma.nu>
References: <33997BDF-F06A-4120-BE72-E41481B5C7EF@adobe.com>
 <527CBCC7.70506@apache.org> <527CCECC.5030004@apache.org>
 <60ACD7D5-B80C-4AE4-9EAC-A49130CC2DD2@adobe.com>
 <5280BB37.6010401@apache.org>
 <CAOFYJNacQnH2o4hooXnC-A3JrAXmWJ-GFWvcXgDV3qTdpHSsdQ@mail.gmail.com>
 <528B79FD.8030809@douma.nu>
From: Jukka Zitting <jukka.zitting@gmail.com>
Date: Thu, 21 Nov 2013 13:18:30 -0500
Message-ID: 
 <CAOFYJNaDHayoCgB0w+etpPwz+8vaOJ2g3qMGB7=J1TmmRBsWGQ@mail.gmail.com>
Subject: Re: Observation
To: Oak devs <oak-dev@jackrabbit.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

On Tue, Nov 19, 2013 at 9:47 AM, Ate Douma <ate@douma.nu> wrote:
> On 11/11/2013 07:29 PM, Jukka Zitting wrote:
>> Of course section 12.6.2 contradicts that by essentially giving the
>> repository free reign to decide which (if any) events to include in
>> the journal.
>>
> Far more problematic (broken really) is the fact that the spec. uses Dates
> to access/order (skipTo) the events. Which is unreliable and useless in a
> clustered environment. Meaning: unreliable for any serious use-case.

Right. It only works for cases where the client won't mind seeing
duplicate events at skip boundaries (and has a clock that's in sync
with that of the repository).

> I'm not following the current state of things at Oak enough to know if it
> also will provide some kind of guaranteed orderable and cluster-wide
> transaction revision/timestamp/whatever.

We indeed do have that. It's possible for a client to "checkpoint" a
repository at a specific revision and later get the exact set of
changes between that checkpoint and any later state of the repository.
For example the asynchronous index update task uses this feature to
periodically update the index with changes that occurred between two
checkpoints.

BR,

Jukka Zitting