I am running vCO 5.5.1.
I have a workflow that allocates an IP address which are stored in configuration items. Kind of like a home gronw IPAM system. To avoid handing out double ip addresses I am using the lockingSystem of vRO.
But here is the problem: When two workflows request the lock at exactly the same time they both get the lock and I end up with duplicate IP addresses.
In my opinion this should never happen. Is this a known problem? Anything I can to to avoid thig other than adding random delay at the start of the script?
To avoid any issue I lock and unlock from a main workflow that call a nested sub workflow. This is what I have implemented in the configuration resource package that is uploaded in the document tab.
What do you mean by "they both get the lock"? That two concurrent calls of LockingSystem.call(lockid, owner) with the same lockid both return true?
Could you show excerpts from your scripting code where you try to acquire the locks?
Actually.... It seemed that way because both were writing the same data to a CE. But it turns out the lock wasn't the problem.
I did the locking inside a script. Apparently the contents of the CE are loaded into the JS context when the script is started. This means both scripts that started at the same time read the exact same contents of the CE while the first script had already changed it.
I put the lock in an additional script element and now it seems to be working just fine.
This is what I thought happened to you.
The workflow attributes, including configuration elements, resource elements are loaded when the workflow start. This is why you need to lock, start a nested or parallel workflow / unlock. This forces the config to be loaded between the lock and the unlock.
thanks. That's really helpful. I changed my workflow and I'll do some more testing. Kinda hard to replicate the concurrency/race condition problem so it will take some time.