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.
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.
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.
One more question. Still assuming that the debug mode is the culprit, since it is a plausible version, and so far I haven’t met with this bug outside of it… well, knowing that debugging is the reason may be nice, but the need for debugging is not magically going to disappear, so what can I do to diminish the probability of locking the storage even when in debugging mode?
As you said you need to put the steps into a child service and remember not to step into it 
Sorry not better choice than that at the moment.
Also make sure you set ‘watt.server.storage.lock.maxDuration’ so that locks do eventually get released.
As an aside the caching service can be reliable if used in conjunction with Terracotta or bigMemory.
regards,
John.
As you said you need to put the steps into a child service and remember not to step into it
Yes, I hoped that it’d be a solution… but apparently it wasn’t. Even though Get and Put are separated each into their isolated flowservices, and it’s the parent service is that gets debugged, I’m still getting the lock.
Also make sure you set ‘watt.server.storage.lock.maxDuration’ so that locks do eventually get released.
The documentation I found on that implies that necessary setting can be found in “Settings > Extended Settings screen in Integration Server Administrator”, but I can’t seem to find that. Either I’m looking the wrong way, or I lack clearance to access that.
Did you check under “Preferences” Tab?
In regular IntegrationServer it is under Settings → Extended Settings, but it might not be visible by default, so you have to go to “Show and Hide …” and select the propery to be displayed.
See IS IntegrationServer Administrators Guide for details.
Check if there is something similar for webMethods.io.
Regards,
Holger
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
