var lockId = "vm-478";
System.log( "Try to lock with lockId:'" + lockId + "' for owner:'" + owner + "'" );
LockingSystem.lockAndWait( lockId, owner );
System.log( "Locked id:'" + lockId + "' for owner:'" + owner + "'");
System.log( "I'm doing my job..." );
//do some job.
System.log(" ... Job done !" );
LockingSystem.unlock( lockId, owner );
System.log( "Unlocked id:'" + lockId + "' for owner:'" + owner + "'");
Probably it is a good idea to do the unlocking in try-finally. Otherwise, it would be very easy to end up with a locked objects while you are developing your workflow. Are we sure that the community will understand this implications?
Often the operations during a lock are not a piece of scripts but other actions and workflows so it is needed to have all of these using an exception link to undo what was done and unlock (which is the equivalent of a try / finally at a workflow level).
I have used the locking system very often. One use case is when you need to generate a new VM / vApp name with checking the ones in the inventory (for example just adding 1 to the number finishing the VM name). Without the lock you may generate two VMs with the same name.
Another use case is when reading / writing in a config element that may be opened / modified by another workflow.
Christophe.
Hi,
A question on Locking. I am trying to use Infoblox pluging for reserving an IP and this workflow has to be executed only 1 at a time. hence I was wondering if I could use locking procedure so that any other request from vcac for this workflow must fail or queued for certain amount of time say ~10seconds.
I see that there are two main parameters required: Lock Id and owner.
Can I add the ID of the workflow here and who would the owner be.?
Thank you.
I'm not sure if this is what you're asking, but there is a lockandWait method. The description is "Try to acquire a lock and wait until lock is acquired." I'm not sure the difference of that and just the .lock method instead. Anyway to use it, you'll put in the name of a string, such as machine name, and owner. For owner, to use a workaround of sorts, I just put in the system time.
So, it'll look like this: LockingSystem.lock(or lockAndWait)(machineName, System.getCurrentTime()); Remember that machineName is a string variable.
Actually, if the original poster is still around, one thing I'm having trouble with is using the .unlockAll() method. It's just not working when I do: LockingSystem.unlockAll(). Every other method for LockingSystem has worked but this one.
I found this thread when I was looking into the locking system of vCO. Thanks for sharing the information!
Since there is not a lot of information out there about this I did a quick write up on my blog. Check it here if you're interested: http://automate-it.today/vco-lockingsystem/
This seems to be working great on existing resources of external systems, but what if I want to lock a workflow object, so a specific workflow may not be run parallel? I tried using the workflow ID for locking. Besides that this dosn't work it would be not reliable, since the workflow ID may change when exporting / importing / changing the workflow which should be locked. Is there a way to do that?
Some more information what the locking system is doing EXACLY would be great. How is locking implemented in vCO? when does the check happen and how? What id should be submitted - the vCO internal ID of the resource (e.g. UUID) or the external ID some plugins use (like the MOB ids that the vsphere plugin is using).
rszymczak
* Workflow IDs do not change when exporting/importing/changing the workflow.
* On how the locks work - there is a database table named VMO_Lock. lock() inserts a new record in this table which may fail if there is already another lock with the same lock ID. lockAndWait() tries to insert a new record in this table; if there is another lock with the same lock ID, it re-tries every 2 seconds to acquire the lock. unlock() removes the given lock record from the table. unlockAll() removes all lock records.
* You can use whatever IDs you want as long as they are < 100 characters in length - UUIDs, external IDs, etc.
chrisheartland
There was a bug in unlockAll() code which was fixed back in June, so it should work in the next vCO release (5.5U2)
Is this the bug with unlockAll() KB2080726?
Yes, this is the relevant knowledge base article.
So the "lock" will not "lock" the ressource automatically? Every workflow that wants to access a ressource has to implement a check for the lock (by using lockAndWait()) in order for the locking to work?
Every workflow that wants to access a shared resource in "a nice way" has to implement such check, but is not forced to do so. The resource is still accessible without such check.
Sort of "cooperative locking".
Just had the chance to try it out and it work's great. The only thing that was not clear to me is that I would have to do the checks myself. The documentation dosn't state anything on that topic and I was thinking vCO will "somehow" handle locking. Now it's quite obvious vCO only maintains a list using the string attributes provided and will fire events if a key-pair (the lock I'm waiting for) is removed.
Cool feature!