[
https://issues.apache.org/jira/browse/OAK-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek updated OAK-6435:
-------------------------------
Fix Version/s: (was: 1.8)
> 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
> Assignee: Tomek Rękawek
> Priority: Minor
>
> 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,
> * for each store, apply the appropriate changes,
> * if some merge() operation fails:
> ** revert changes already applied in the previous stores, by merging the
> reversed builder (nodeState swapped with baseState),
> ** 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)
