Cache Concurrency
JADE enables you to optimize locking based on the frequency at which an object is updated, by specifying that an object has one of the following categories.
-
Volatile, indicating that the object is often updated (the default)
Objects are volatile by default. Volatile objects are locked and unlocked in the usual manner; that is, a volatile object is recorded as locked by any processes that have it locked until they unlock it, and whenever locked, the latest edition of the object is fetched from the database.
-
Stable, indicating that the object is updated infrequently
The infrequency of update allows an optimization to avoid having to request the JADE database server to fetch the latest edition of an object from the database every time an object is shared locked. Instead, when a shared lock on a stable object is first obtained on a specific node, as well as being locked by the requesting process it is deemed locked by that node.
This "node lock" remains in place even after the process unlocks the object so that the next time a process requests a shared lock on that object, there is no need to fetch the object from the database if the node lock is still in place. If no processes have the stable object shared locked, the node lock remains in place until the object is swapped out of cache or a process on any node requests an exclusive lock on the object. For details, see "Stable Objects", later in this chapter.
-
Frozen, indicating that the object is not updated
The frozen volatility state allows an optimization that assumes a frozen object in cache is always the latest edition and that there is no need to keep fetching the object from the server node or indeed to record the object as locked in response to shared lock requests.
As frozen objects cannot be updated, you must first change the volatility of a frozen object. You should do this with extreme caution, as other processes using the object do not necessarily know that it has been updated, even though those processes may have the object shared locked. For details, see "Frozen Objects", later in this chapter.
An example of where the volatility feature can provide benefit is when iterating through collections, using iterators or the foreach instruction. Making a collection stable or frozen improves performance, as there is no need to request the server to fetch the collection header object from the database every time the collection is to be iterated in response to the implicit shared lock requests associated with iterating collections.
The Schema Inspector displays class and object volatility by default, which enables you to check whether objects and collections are set to stable or frozen without having to write code to determine the volatility state of an object or collection.
Frozen and Stable volatility applies to persistent objects only. All transient objects are considered Volatile.
The
| Global Constant | Integer Value | Description |
|---|---|---|
| Volatility_Frozen | #04 | Object is frozen (that is, it is not updated) |
| Volatility_Stable | #08 | Object is stable (that is, it is updated infrequently) |
| Volatility_Volatile | #00 | Object is volatile (that is, it is updated often) |
