[
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)
