[jira] [Commented] (OAK-6435) Atomic commits for the composite node store

["Marcel Reutegger (JIRA)" <ji...@apache.org>]

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

Marcel Reutegger commented on OAK-6435:
---------------------------------------

What about the constraints that are repository global? I remember discussions in the past that these cannot be enforced easily with a composite node store working entirely in read-write mode. E.g. with read-only stores mounted into a writable one, OAK-4891 would ensure those constraints. How does this work when all stores are writable?

Also note, a simple (in-memory) lock won't work when one of the stores is part of a cluster and therefore distributed. In this case the lock would have to be acquired globally, which can be expensive.

> Atomic commits for the composite node store
> -------------------------------------------
>
>                 Key: OAK-6435
>                 URL: https://issues.apache.org/jira/browse/OAK-6435
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: composite
>            Reporter: Tomek Rękawek
>             Fix For: 1.8
>
>
> Right now, the CompositeNodeStore only supports the setups with a single read-write store. All the other stores have to be configured in the read-only mode.
> A necessary (but probably not sufficient) condition to support multiple read-write stores, is making sure that the merges are atomic - either the whole merge() operation is done (which means merging the changes with all the partial stores) or no changes are made. Eg. in a case that a partial merge() fails we need to revert changes already made on all the other stores.
> For more details, see discussion in the OAK-6425 and the [~mduerig] comment:
> bq. I wouldn't do this as supporting multiple rw stores is an entirely different story and can't be done just in passing. To ensure our constraints we would need some sort of ACP (e.g 2PC) here. A simple lock won't do.
> In this issue we'll try to introduce atomicity for the composite node store. The first approach, similar to the 2PC protocol, is to apply changes sequentially and revert all of them if one of the stores fails.
> The proposition for the algorithm is as follows:
> * acquire a write lock,
> * call getRoot() on all the stores,
> * for each store, apply the appropriate changes,
> * if some merge() operation fails:
> ** revert changes already applied in the previous stores, by merging them to the root states got in the first step,
> ** if reversing the change is not possible, log a warning and carry on with reversing on all the other stores,
> * release the lock.
> An alternative approach would be using checkpoints rather than getRoot() references in the first step. If we have a {{NodeStore#restore(String checkpoint)}} method, the whole process would be more straight-forward. On the other hand, creating and releasing checkpoints for each merge, inside the critical section, may not be an optimal solution.
> //cc: [~mduerig], [~chetanm], [~mreutegg] - any feedback?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)