Slightly off topic: the thought that the copy on read/write indexing features may need to be explicitly managed in such a setup just occurred to me.
I.e. when an instance is switched to the copy on write node store, the local index directory will deviate from the "mainline" node store. Upon switching the instance back to the "mainline" (i.e. disabling copy on write node store), the local index directory may need to be deleted? Or maybe it is already resilient enough to automatically recover. Regards Julian On Tue, May 30, 2017 at 10:05 AM, Michael Dürig <[email protected]> wrote: > > > On 30.05.17 09:34, Tomek Rekawek wrote: >> >> 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. > > > Ok I see. I think the fact that these classes are not for production use > should be stated in the Javadoc along with what clarifications of what can > be expected from the store wrt. interleaving of calls to various mutators > (e.g. enableCopyOnWrite() / disableCopyOnWrite() / merge(), etc.). I foresee > a couple of very sneaky race conditions here. > > Michael
