Hi Vikas, On 8 August 2016 at 14:13, Vikas Saurabh <[email protected]> wrote:
> Hi Ian, > > On Sun, Aug 7, 2016 at 10:01 AM, Ian Boston <[email protected]> wrote: > > Also, IIRC, the root document is not persisted on every commit, but > > synchronized periodically (once every second) similar to fsync on a disk. > > So the indexes (in fact all Oak Documents) are synchronous on the local > Oak > > instance and are synchronous on remote Oak instances but with a minimum > > data latency of the root document sync rate (1s). IIUC the 1 second sync > > period is a performance optimisation as the root document must be updated > > by every commit and hence is a global singleton in an Oak cluster, and > > already hot as you point out in 3. > > > > Just to clarify a bit. There are potentially 2 updates that can modify > root document. > With every commit, oak (document mk) defines a document to be > commit-root. That's root of the sub-tree which changes. A commit is > successful if commit-root could be conditionally updated (condition to > see if the commit conflicted with something else or not). With > synchronous prop indices, commit root usually is at root - so each > successful commit would write to root. That's what Michael was > pointing to in point3. > The other update is about asynchronous update of _lastRevs - _lastRevs > control visibility horizon. For local nodes, a pending list of updates > is kept in memory so local sessions/builders get to see committed > changes. These are pushed to persistence mongo during background > update which defaults at 1 s interval. So, other cluster nodes don't > see changes immediately. > Thanks for the explanation. I learnt something more. If every successful commit writes the root node, due to every update updating a sync prop index, this leaves me wondering how the delayed sync reduces the writes to the root node ? I thought the justification of the 1s sync operation was to reduce the writes to the root node to n/s where n is the number of instances in the cluster, however based on what you are telling me the rate is (m+n)/s where m is the total commits per second of the whole cluster. I understand that the update to test for a conflicted commit may not be the same as the update of _lastRevs, but in MongoDB both update the MongoDB document. Best Regards Ian > > Thanks, > Vikas >
