Expiration Time to Live and Tuple Locking
ActiveSpaces provides configuration settings that control the following:
- When data expires and can be evicted from a space
- How long a tuple remains locked when an application has locked it
To control eviction and how long tuples remain locked, ActiveSpaces allows you to specify the following values:
- Entry TTL - Controls how long a tuple can remain unmodifed before it is evicted from the space.
- Lock TTL - controls how long a tuple remains locked after an application has locked it.
- Lock Wait - How long an operation attempting to modify a locked tuple can block while waiting for a tuple lock to clear.
Entry TTL
ActiveSpaces is a durable data store that can be used as a cache. Tuples stored into a space are not evicted from the space to make room for new tuples unless the space is specifically configured to evict tuples after a specified time. Therefore, you can use a space as a system of record.
In some cases you might want to have an automated garbage collection mechanism operate on the space to expire old, obsolete tuples from it. To do this, you can define a time-to-live (TTL) for tuples stored in the space. The TTL is the number of milliseconds that must elapse since the tuple was created or last modified before it is considered for expiration.
You can set or return the entry TTL using the SpaceDef objects’s setTTL and getTTL methods, respectively.
Lock TTL
Applications that have joined a space can lock tuples in the space. By default, locked tuples remain locked until the application that created the lock clears it, or until that application disconnects from the metaspace, whether in an orderly manner or not.
To avoid potential deadlock situations, you can also possible set a maximum lock-time-to-live for a space, which specifies that if an application does not clear a lock on its own within a certain number of milliseconds, the lock is automatically cleared.
You can set or return LockTTL can be set or returned using the SpaceDef objects’s setLockTTL and getLockTTL methods, respectively. It is expressed in milliseconds and defaults to TTL_FOREVER.
LockWait
While a tuple is locked, no space member besides the creator of the lock can perform a Put or Take operation on it. Therefore, distributed applications in which multiple instances of the application make concurrent modification to the data stored in a space should always ensure that they lock tuples for the shortest possible amount of time to maximize concurrency of the overall process.
If you expect that the locks on tuples in the spaces will have a very short duration, ActiveSpaces allows you to specify a LockWait value for the space. The LockWait value is the number of milliseconds an operation attempting to modify a locked tuple can block while waiting for the lock to clear.
If at the end of the LockWait period, the tuple is still locked, then the operation to modify that locked tuple throws an exception indicating that the operation could not be performed because the tuple is locked. The LockWait value of a space is also taken into consideration if a member attempts a non-transacted operation that conflicts with uncommitted data (for example, tuples about to be replaced by uncommitted operations are locked by that transaction).
You can set or get the LockWait value by using the SpaceDef object’s setLockWait and getLockWait methods, respectively. Lock wait value is expressed in milliseconds. The default value is NO_WAIT, indicating that this feature is not used, and that an operation attempting to modify a locked tuple will immediately return with a failure indicating that the tuple is currently locked.
For detailed information on the procedure for setting a LockWait value, see Specifying a LockWait Value for a Put.