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.
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.