Entry Locking

To maintain data integrity, the short-term store uses locking to ensure that multiple threads do not modify the same entry at the same time. For insertions and removals, the short-term store sets and releases the lock. For updates, the client must set and release the lock. Using locking improperly, that is, creating a lock but not releasing it, can cause deadlocks in the short-term store.

The following guidelines can help you avoid short-term store deadlock:

Release locks in the thread through which they were set. In other words, you cannot set a lock in one thread and release it in another. The safest way to do this is to release each lock in the flow service that acquired it.

Unlock entries before the flow completes. Entries remain locked until released via a put (pub.storage:put) or an explicit unlock (pub.storage:unlock). To accomplish this, always pair a call to pub.storage:get or pub.storage:lock with a call to pub.storage:put or pub.storage:unlock so that every lock is followed by an unlock. In addition, use a Try-Catch pattern in your flow service so that an exception does not prevent the flow service from continuing and releasing the lock.

Set limits on how long the threads will wait for a lock to be set or released. By setting finite limits, you allow the pub.storage service to release locks after a set amount of time and thereby avoid a deadlock situation. For more information, see Wait Time and Duration.

Following these guidelines might not be sufficient in some situations. For example, an Integration Server or hardware crash might result in a prematurely terminated flow service, thereby leaving an outstanding lock on the pub.storage service. Or, a client flow service might hang while requesting a lock. In these situations, having limits on how long a lock can exist (duration) or how long a lock request will wait (wait time) can prevent an application deadlock while using pub.storage services. For more information about lock duration and wait time, see Wait Time and Duration.