Hello Michael, thanks for the reply!
> On 30 May 2017, at 09:18, Michael Dürig <[email protected]> wrote: > 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. Indeed, it would be much simpler. However, the main purpose of the new feature is testing the blue-green Sling deployments. That’s why we need the DocumentMK to support it as well. Regards, Tomek -- Tomek Rękawek | Adobe Research | www.adobe.com [email protected] > > > > 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://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fsecure%2Fattachment%2F12868273%2FOAK-6220-3.patch&data=02%7C01%7C%7Cb4d5c84e0fc141ccc03b08d4a72c2496%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636317255425935320&sdata=i0XxBrunLWPWgIAhMqkr4F8Pfo1ktHNFlJ2V1H%2FpmQg%3D&reserved=0
