[OAK-6435] Atomic commits for the composite node store

• Type: Improvement
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Component/s: composite
• Assignee: Tomek Rękawek
• Reporter: Tomek Rękawek
• Created: 07/Jul/17 16:58
• Updated: 20/Nov/17 09:02

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:

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?

Issue Links

• is related to: OAK-6425 Make the CompositeNodeStore thread-safe