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

["Tomek Rękawek (JIRA)" <ji...@apache.org>]

Tomek Rękawek created OAK-6435:
----------------------------------

             Summary: 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)