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 -- Tomek Rękawek | Adobe Research | www.adobe.com [email protected]
smime.p7s
Description: S/MIME cryptographic signature
