Why does flowservices' Storage get locked and what to do if it does?

Hi,

while working with webmethods.io flowservices, I’m trying to utilize Storage Get/Put feature to keep track of run times, but sometimes the key gets locked for no apparent reason. I’m 100% positive no one but me works with that storage, so no operations I’m unaware of. Am I doing anything wrong? What needs to be done to avoid locking and is there a way to force unlock a record that got stuck outside of the current process?

Thanks.

Flowservice Storage Lock

Hi,

what about explicitly locking the storage before trying to put new value into it?

In this case you are aware of the lock identifier and can use it in the put and unlock operation.

Regards,
Holger

Not sure what “lock identifier” you’re talking about. The Lock operation does not produce any return:

As for locking with explicit storename/key parameters - yes, I’ve tried that, and it still sporadically finds itself locked with no unlock possibility.

Locking is based on the current thread. You don’t need to unlock after using put. put automatically unlocks once it has completed. Therefore neither lock or unlock should be needed.

Are you trying this in debug mode? If so, that might be your problem as potentially each step might get executed by a different thread and hence might cause issues.

I would perhaps recommend that you use the caching services rather than storage.

regards,
John.

1 Like

I’m not convinced that caching is a reliable way to keep consistent data between sessions. The debug mode version, though, seems promising. I’ll try to move all storage operations into a separate flowservice that would be performed in a single click even when debugging, and see if the problem persists.

Also, while figuring out reasons of locking may or may not be fruitful, there’s still remaining question of what to do if the locking took place. The locked key may stay locked for hours, and assuming that it happened due to a botched debugging, there seems to be no way to kill the offending thread, as debugging tasks are not shown in wm.io’s Monitor page, and simply closing a browser tab is not enough to close the cloud process it started.