jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomek Rękawek (JIRA) <j...@apache.org>
Subject [jira] [Assigned] (OAK-6435) Atomic commits for the composite node store
Date Mon, 24 Jul 2017 20:31:00 GMT

     [ https://issues.apache.org/jira/browse/OAK-6435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

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

    Assignee: Tomek Rękawek

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

Mime
View raw message