Hi Tomek,
AFAIU from your mail and from looking at the patch this is about a node store implementation that can be rolled back to a previous state.
If this is the case, a simpler way to achieve this might be to use the TarMK and and add functionality for rolling it back. The cleanest way would be to add a method SegmentNodeStore.rollBack(String checkpoint), whose implementation is basically a call to Revisions.setHead(...) passing the state of the checkpoint. Implementation wise there might be a few hoops as there is this probably needs to be looped through the Scheduler. But I guess Andrei might be able to help out on the details here.
Michael On 29.05.17 10:50, Tomek Rekawek wrote:
Hello, in the OAK-6220 I’m exploring a topic of having a switchable copy-on-write node store implementation. The idea is that the “main” node store (eg. DocumentMK) is wrapped with an extra layer (copy-on-write node store), which can be turned on/off in the runtime. When the copy-on-write is turned on, all the new changes are not merged with the main store, but kept in a separate, volatile store. The new mode is meant to be used for testing - so we can perform even destructible tests and then reverse all the changes seamlessly. It’s especially useful in the blue-green deployments with CompositeNodeStore and DocumentMK, since we can test the new version of the application on the new (green) instance, even if the tests requires changes in the node schema. The changes won’t be propagated to the old (blue) instance as long as the COW mode is on. Together with other people involved in the issue we had 3 ideas how this can be implemented: 1. By copying the / node and its subtree into some private location and then mount the COW store on top of it. This works fine for the SegmentMK (supporting the copy-by-reference), but not with the DocumentMK (which actually copied the whole tree). Since the new feature is more useful with DocumentMK, we needed to find something else. 2. By storing the data in a NodeBuilder taken from the store without merging it back to the main repository. This seemed to worked fine, but because of the DocumentMK limitations (OAK-1838) this wasn’t reliable. 3. By creating a MemoryNodeStore on a top of the recent root state This is the current implementation, it works fine [1]. The newly created MemoryNodeStore didn’t contain any checkpoints, so some extra layer (BranchNodeStore) was introduced to inherit the already existing checkpoints from the main store. Another layer (CowNodeStore) is being used to dynamically switch between the main and the branch node store. Potential limitation here is that the changes have to fit into memory. Switching the repository into COW mode and forgetting about this is not a good idea. I’d like to merge the [1], so the blue-green Sling deployments can be tested in the more robust way. Any thoughts? Regards, Tomek [1] https://issues.apache.org/jira/secure/attachment/12868273/OAK-6220-3.patch
