A stable object is one that is mostly read, and only infrequently updated.
For stable objects, each node retains a generic node shared lock, recorded on the server node and the local client node, even after JADE sessions have unlocked the object. Shared lock entries for individual JADE sessions are recorded only on the local client node. The node’s shared lock is released when a JADE session requests an exclusive lock on the object, when the object is swapped out of the client node’s object cache, or when the client node terminates.
Using stable objects avoids the overhead of communication with the database server node to acquire a shared lock and retrieve the object from the JADE database. This is because while a node lock is in place, the lock can be handled locally, and the copy of the object in cache is the latest edition, because the object cannot be updated while the client node’s shared lock is in place.
When an exclusive lock is requested on a stable object, all client nodes that have node shared locks for that object are asked to release the lock. The client nodes release the lock when no JADE sessions on that node have the object locked.
To prevent the exclusive lock request from being held up by other shared lock requests, further lock requests are blocked until after the exclusive lock has been acquired and released (or the request times out).
Requests for reserve locks and update locks are handled normally. Node locks are not involved, as these lock types are compatible with shared locks. In addition, requests for shared locks of session duration are handled normally, and do not involve node locks.
An example of a good use of stable objects would be for JADE collections that are frequently enumerated but infrequently updated.
The trade-off is that although stable objects optimize the acquisition of shared locks, acquiring exclusive locks involves extra overhead, as all client nodes that are holding node locks need to be requested to release the locks first.
Another factor to consider is that using stable objects can result in an increase in the number of locks held in the server node’s lock tables, because shared locks tend to be retained for longer. For very large numbers of concurrent locks (10,000 or more), it may be beneficial to increase the value of the
Node locks are identifiable when lock information is displayed by the JADE Monitor, as node locks have the kind property set to LockKind.Node.
Local shared locks on stable objects (that is, locks held on client nodes by JADE sessions where a node lock is involved) have the kind property set to LockKind.Local.
Other locks have the kind property set to LockKind.Normal.
The following diagram shows the locks recorded for stable objects.
This example illustrates that shared locks for individual JADE sessions are recorded locally on the session’s client node, whereas a node lock is recorded on the client node and the database server node. Exclusive locks are recorded on the client node and database server node, in the same manner as volatile objects.
For convenience, node locks use the client node’s JADE background session as the session that has the lock.
