I have just release a new plugin to solve a current common issue with Bubble: race conditions.
Bubble suffers from concurrency issues (two workflows could potentially read/write the same piece of data in the database). Using this plugin will allow you to acquire a lock, so other workflows trying to acquire the same lock will not be allowed to, until the lock is released.
Think of locks as a semaphore. Process A acquires a lock and then starts doing its work. If process B wants to acquire the same lock, and it’s not been released by process A, it will fail so it will have to wait until the lock is released by process A (or expires).
Does the plugin cause process B to fail and then wait and trigger automatically once the lock is released? Or does the plugin just cause process B to fail?
Currently process B would get a success == false when trying to acquire the lock that was previously acquired by process A, and would need to retry to acquire the lock until sucess == true. So process B doesn’t wait until the lock is released.
Is the lock something that is in the DB or possible to make a DB data field to utilize the backend workflow trigger so that it is able to ‘listen’ for when the lock is available again so that it can be ‘automated’?
That’s something I could develop for future releases, although right now you could achieve that by having process B loop whilst the lock is taken by a different process.
I hear you @justin.hume. The problem is that this plugin does have some variable costs to run based on usage, therefore it’s not possible to offer a purchase option.
What would be a reasonable monthly charge for you?
I can offer you a free month to test if you would like to be sure it does solve your issues.
cool plugin.
If A is trying to access a free lock, and gets it (locks it ) and the B tries to unlock the same lock, and fails (because it is taken) will B automatically perform the action after A frees the lock or do we need to re-initialise process B ?
Regarding your question, the un-lock action is a one-off action, so whether it succeeds or fails, it won’t automatically be run again. Therefore, in your example, if you need process B to un-lock a lock, you will need to run the un-lock action as many times as needed until the un-lock action returns success.
But in your example, if process A has the lock, process B will never be able to unlock it, as it never got the lock in the first place. A process can only un-lock a lock if it acquired it beforehand.
What scenarios are you thinking? Perhaps I am not understanding your problem properly.
