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. BR, Jukka Zitting
