Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 3 Performing Basic TIBCO ActiveSpaces Tasks : Managing Expiration and TTLs

Managing Expiration and TTLs
This section explains the concepts of expiration, time-to-live (TTL), and LockTTL as they are used in ActiveSpaces.
Entry TTL ActiveSpaces is a durable data store that can be used as a cache. This means that tuples stored into a space will not be evicted from the space to make room for new tuples unless the space is specifically configured to evict.
For this reason, a space can be used as a system of record. However, in some cases it is convenient to have an automated garbage collection mechanism built into the space to expire old, obsolete tuples from it. To do this, you can define a time-to-live for the tuples stored in a space. The TTL is the number of milliseconds that must have elapsed since the tuple was created or last modified before it will be considered for expiration.
The entry TTL can be set or returned using the SpaceDef objects’s setTTL and getTTL methods, respectively. The default value (DEFAULT_ENTRY_TTL) is TTL_FOREVER, which means that tuples in the space never expire. When a tuple expires from the space, an event of type EXPIRE_EVENT is automatically generated and can be caught by applications by using a listener or event browser on the space.
LockTTL Applications that have joined a space have the ability to lock tuples in that space. By default, locked tuples will remain locked until either the application that created the lock clears it, or until that application disconnects from the metaspace, whether in an orderly manner or not. However, 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.
The 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 an operation on it other than a get. For this reason, 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 in order to maximize concurrency of the overall process.
If there is an expectation that on a space the locking of tuples will be a very short-lived event, ActiveSpaces can greatly simplify the application programmer’s job by providing the ability 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 will throw 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).
The LockWait value can be set or gotten using the SpaceDef object’s setLockWait and getLockWait methods, respectively. It 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.

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved