[
https://issues.apache.org/jira/browse/OAK-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek updated OAK-6435:
-------------------------------
Description:
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?
was:
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?
> 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,
> * 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)
