+1. We use locks for implementing sequences. Would make it tricky for us when this is removed.
I've tried the atomic counter stuff to see if it could be adopted, but it's not suitable for this purpose on mongodb clusters. On Mon, 9 Sep 2019 at 17:36, Søren Jensen <[email protected]> wrote: > > Hi > > I see through OAK-6421 that locking is being phased out and is > currently deprecated. Since the Jira issue currently has the fix > version set for the next stable release, I have some questions for > this. > > For our current setup, we have a non-distributed application in which > users may reserve documents and folders of documents for long periods > of time. Currently, we represent this through locks, such that any > invalid attempts at modifying a resource reversed by somebody else > results in a LockExpection. Furthermore, for reserving folders (and > underlying contents) we make use of deep locks. > > Question 1: > After JCR locking has been phased out, would we then need to develop > this locking functionality ourselves to obtain similar semantics? Or > is there any good solution that would ease the transition for our > non-distributed application? > > Question 2: > We already have existing repositories containing open-scoped locks. At > this point, is there a plan for how locked nodes are migrated to a > version without locking? Specifically, I’m curious about: > - Will all of the locked nodes prior to upgrade now appear as unlocked > afterwards? > - If they do become unlocked, will there be any way of knowing what > nodes were locked prior to upgrade? > > Thanks in advance. > > Regards, > Søren Jensen -- -Tor
