You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Søren Jensen <so...@gmail.com> on 2019/09/08 20:52:22 UTC
Questions regarding phasing out of JCR locking - Oak
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
Re: Questions regarding phasing out of JCR locking - Oak
Posted by Chris Poulsen <cp...@dezide.com>.
Hi,
Still on Jackrabbit atm. but would like to move to Oak at some point. (Have
been avoiding using features that are not included on Oak as much as
possible)
We are also using (shallow) open scoped locks to prevent various
concurrency issues (protect id counters and as part of our optimistic
locking of content), it would be good to have some sort of locking
mechanism (preferably at node level) in the toolbox when moving to Oak.
--
Best Regards
Chris
On Mon, Sep 9, 2019 at 3:23 PM Julian Reschke <ju...@gmx.de> wrote:
> On 08.09.2019 22:52, Søren Jensen 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.
>
> Are you aware that in Oak, these modifications actually are not
> prohibited by locks?
>
> (That's the reason it's deprecated; it doesn't work as advertised...)
>
> > ...
>
> Best regards, Julian
>
Re: Questions regarding phasing out of JCR locking - Oak
Posted by Julian Reschke <ju...@gmx.de>.
On 08.09.2019 22:52, Søren Jensen 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.
Are you aware that in Oak, these modifications actually are not
prohibited by locks?
(That's the reason it's deprecated; it doesn't work as advertised...)
> ...
Best regards, Julian
Re: Questions regarding phasing out of JCR locking - Oak
Posted by Piotr Tajduś <pi...@skg.pl>.
On 09.09.2019 14:53, Torgeir Veimo wrote:
> +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.
>
I had to move my sequence generators to mongo when I started to use more
than one oak node in cluster. I implemented it using write lock on
collection item. Below my sequence generator, maybe it will be usefull
for you.
@ApplicationScoped
public abstract class BaseMaxidService {
@Resource(lookup="java:/mongoOAK")
MongoClient mongoClient;
MongoDatabase db;
MongoCollection<BasicDBObject> collection;
protected abstract String getDbName();
@PostConstruct
protected void initialize(){
db = mongoClient.getDatabase(getDbName());
collection = db.getCollection("maxid", BasicDBObject.class);
}
public Long getMaxid(String systemName,String keySection, String
keyName) {
String id = systemName+"/"+keySection+"/"+keyName;
Bson filter = Filters.eq("_id", id);
FindIterable<BasicDBObject> fresult = collection.find(filter);
BasicDBObject maxid = fresult.first();
if(maxid==null) {
maxid = new BasicDBObject();
maxid.put("value", 1L);
maxid.put("keyName", keyName);
maxid.put("systemName", systemName);
maxid.put("keySection", keySection);
maxid.put("_id", systemName+"/"+keySection+"/"+keyName);
collection.insertOne(maxid);
}
BasicDBObject update = new BasicDBObject();
update.put("$inc", new BasicDBObject("value", 1));
BasicDBObject result = collection.findOneAndUpdate(filter, update);
return result.getLong("value");
}
}
> On Mon, 9 Sep 2019 at 17:36, Søren Jensen <so...@gmail.com> 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
Re: Questions regarding phasing out of JCR locking - Oak
Posted by Torgeir Veimo <to...@gmail.com>.
+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 <so...@gmail.com> 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