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 <[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
