On 11/21/2013 07:18 PM, Jukka Zitting wrote:
Hi,
On Tue, Nov 19, 2013 at 9:47 AM, Ate Douma <[email protected]> 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.
Good to hear, then we should be OK porting our functionality to Oak when that
time comes :)
Thanks for the heads-up!
Ate
BR,
Jukka Zitting
