DiffusionTM Android API 6.5.2
public static interface Session.SessionLock
Session locks are identified by a lock name. Lock names are arbitrary and chosen at will to suit the application. Each lock is owned by at most one session. Locks are established on demand; there is no separate operation to create or destroy a lock.
A session lock is acquired using the
If no other session owns the lock, the server will assign the lock to the
calling session immediately. Otherwise, the server will record that the
session is waiting to acquire the lock. A session can call
more than once for a given session lock – if the lock is acquired,
all calls will complete successfully with equal SessionLocks.
If a session closes, the session locks it owns are automatically
released. A session can also
release a lock.
When a session lock is released and other sessions are waiting to acquire
the lock, the server will arbitrarily select one of the waiting sessions
and notify it that it has acquired the lock. All of the newly selected
lock calls will complete normally. Other
sessions will continue to wait.
Session.lock(String, SessionLockScope) variant of this method takes
a scope parameter that provides the further option of automatically
releasing the lock when the session loses its connection to the server.
The acquisition life cycle of a session lock from the perspective of a session is shown in the following diagram.
Lock API, there is no
association between a lock and a thread. If a session calls this method
for a lock it already owns, the call will complete normally and
immediately with a
SessionLock that is equal to the one returned
when the lock was originally acquired. A single call to
unlock() will release this session's claim to a lock.
A further difference to
java.util.concurrent.locks.Lock is that
lock ownership can be lost due to an independent event such as loss of
connection, and not only due to the use of the locking API by the owner.
Consequently, the session should poll using
to check that it still owns the lock before accessing the protected
This session lock API has inherent race conditions. 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 access the resource. The races arise for several reasons including
isOwned(), the lock can be lost after the check has succeeded but before the resource is accessed;
Despite this imprecision, session locks provide a useful way to coordinate session actions.
|Modifier and Type||Method and Description|
The scope of the lock.
A value that identifies the acquisition of the lock with the given
Test whether the session lock is still owned.
Release a session lock, if owned.
name. SessionLocks that are acquired later are guaranteed to have bigger sequence values, allowing the sequence number to be used as a fencing token.
The scope determines when the lock will be released automatically.
If a session makes multiple
requests for a lock
using different scopes, and the server assigns the lock to the
session fulfilling the requests, the lock will be given the weakest
scope (UNLOCK_ON_CONNECTION_LOSS). Consequently, an individual
request can complete with a lock that has a different scope to that
On completion, this session will no longer own the named session lock. If CompletableFuture completes normally, a true value indicates this session previously owned the lock and a false value indicates it did not.
If the CompletableFuture completes exceptionally, this
session does not own the session lock. Common reasons for
failure, indicated by the exception reported as the
SessionClosedException– if the session is closed.
Copyright © 2020 Push Technology Ltd. All Rights Reserved.