Client coordination
Clients can coordinate their access to shared resources using session locks.
Session locks
Session locks enable you to implement collaborative locking schemes to manage access to shared resources by multiple clients.
Each lock is identified by an arbitrary lock name and can only be owned by one session at a time.
The main reason to use a session lock is to ensure only one session can update a set of topics.
You might also use a session lock to:
- ensure that at most one session responds to an event
- select a single session to perform a housekeeping task
See Session locks for details of how to use session locks.
Considerations
Consider the following factors when using session locks:
- Session locks are a generic mechanism for you to implement a locking scheme. It is up to you to design a suitable scheme and ensure that each client or other application component follows it appropriately.
- Locks are only associated with sessions. There is no inherent way to associate a lock with a topic, except through your application's logic.
- If a lock is released, and multiple sessions are trying to acquire it, the server will arbitrarily assign the lock to one of the sessions.
- There is a potential for client-side race conditions to arise due to the distributed nature of session locks. Even if an application is coded correctly to protect a shared resource using session locks, there may be a period where two or more sessions concurrently 'believe' they have the lock.
- The server, or cluster of servers, is responsible for assigning the owner and has a single view of lock ownership. When locks are used with an update constraint to ensure a single session can update a set of topics, this view guarantees that only the current owner satisfies the constraint