[jira] [Commented] (OAK-8326) prototype for async commits

["Stefan Egli (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OAK-8326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841399#comment-16841399 ] 

Stefan Egli commented on OAK-8326:
----------------------------------

early sketch of an async node store added to [this branch|https://github.com/stefan-egli/jackrabbit-oak/tree/OAK-8326]:

MemoryAsyncNodeStore:
* this implementation is done on the NodeStore layer
* it uses an underlying NodeStore as a 'target' NodeStore for synchronous commits and flushes (syncs)
* it uses a MemoryNodeStore to keep the async changes
* it doesn't use a mixin yet, but simply checks if on a particular node there is a property "oak:async". if that's the case, from there on down it will treat that part as async
* the conflict resolution is currently only defined globally on the entire MemoryAsyncNodeStore. the idea is that this could be defined on a per node, nodeType, user etc, level
* there isn't any active background synching done yet. but that would be the idea
* the assumption is that checkpoint operations require a sync (flush) first, so those will now sync with the underlying
* if there's a conflict on async synching, it currently just logs an error - but the idea is that it would retry and if that fails it could start using a cluster wide lock to prevent other instances from synching anything. other instances could in theory still read from the underlying to get updates (but that's also not implemented yet)

> prototype for async commits
> ---------------------------
>
>                 Key: OAK-8326
>                 URL: https://issues.apache.org/jira/browse/OAK-8326
>             Project: Jackrabbit Oak
>          Issue Type: New Feature
>          Components: store-spi
>            Reporter: Stefan Egli
>            Assignee: Stefan Egli
>            Priority: Minor
>
> Prototype asynchronous commits in Oak. 
> An asynchronous commit is a change set which contains only nodes that are okay to be merged asynchronously and for which, in case there is a conflict at that later merge time, an async conflict resolution is defined.
> Asynchronous commits are held back locally (potentially) without being written to the underlying NodeStore.
> Asynchronous commits can be mixed with synchronous ones in one particular NodeStore. If a synchronous commit is done, it is applies to the underlying NodeStore as usual. Thus they can potentially result in conflicts thus CommitFailedExceptions.
> Async commits must be acompanied with async conflict resolutions - the latter has earlier been suggested on [the list|https://oak.markmail.org/thread/p2ljif2vag3alktf]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)