Can we lock the configuration element?
Hi,
What do you mean by 'lock the element'? To prevent other people's scripting code to add/modify/delete the element's attributes and their values? If so, then the short answer is 'no', there is no easy/straightforward way to do so.
Out of curiosity, what's the use case?
Not sure about the other person but I would like to use a Config element to generate Cluster names (like MSCS needs). I need to ensure that the other nodes in the vRO cluster are not doing the same thing at the same time and I assign the same cluster name to two different clusters. I am using a database sequence to do that now but it would be faster to use vRO config elements if I knew that it was safe.
Carl L
You can try the LockingSystem functionality in vro.
LockingSystem.lockAndWait(object,owner); - Waits till lock is acquired.
LockingSystem.lock(object,owner); - Returns true is lock is acquired.
LockingSystem.unlock(object,owner);
LockingSystem.retrieveAll();
LockingSystem API could work if you can guarantee that all pieces of code that access your configuration element are using it (it's kind of 'cooperative locking'). It won't prevent access/modification of your configuration element by other code that is not aware of this 'locking'.
Are you saying that in a 3 node vRO cluster, that if I use the locking API, it will still work (aka lock across the 3 nodes)? I understood that was not true but I am always open to correction 🙂
Thanks,
Carl L.
LockingSystem API internally stores lock records in a database table (VMO_Lock). All nodes participating to a vRO cluster are sharing the same database, so yes, locks should work across all cluster nodes.
We use locking in a 2-node cluster successfully with the approach Ilian described. I'd also look into using reload method on a config element before read/write, I recall it was giving us some grief in the past with stale values (vro7.2).