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.
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 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 🙂
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).