Share via


Concurrency Methods (Velocity)

[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]

Microsoft project code named "Velocity" supports optimistic and pessimistic concurrency models. The following sections discuss how the cache client methods align to these models. For more information about concurrency, see Concurrency Models (Velocity).

Optimistic Concurrency Model

In the optimistic concurrency model, updates to cached objects do not take locks. Instead, the cache client first reads the version of the object to be updated and sends that version information together with the updated object. The system only updates the object if the version sent in matches the current version of the object. Every update to an object changes its version number. This prevents the update from overwriting someone else’s changes.

Method Description

Get

Does not take any locks by design; Get always succeeds if the item exists. If the object is being updated, the Get method does not wait and only the current version of the object is be returned.

GetCacheItem

Returns all the DataCacheItem objects. In addition to the cached objects and other information, such as tags, the version information about the objects is also returned.

GetIfNewer

Can be used to check whether the cached object has changed in the data source. To minimize network traffic, the cached object is only returned if a newer version is available.

Add

Does not have any optimistic currency-related overloads. Add either succeeds or fails.

Put

Supports optimistic concurrency by taking version information as an optional parameter; Put only succeeds if the object to be replaced is of the same version.

Remove

Supports optimistic concurrency by taking version information as an optional parameter; Remove only succeeds if the object to be deleted is of the same version.

Pessimistic Locking Model

In the pessimistic locking model, the client explicitly locks objects to perform operations. Other operations that request locks are rejected (the system does not block requests) until the locks are released. When objects are locked, a lock handle is returned (as an output parameter). The lock handle is required to unlock the object. In case the client fails before freeing a locked object, timeouts are provided to release the locks. Locked objects are never expired, but they may expire immediately after they are unlocked if it is past their expiration time.

Note

Transactions spanning operations are not supported. The application that uses cache is responsible for determining the order of the locks and detecting deadlocks, if any.

The following table shows the methods that you can use to lock and unlock an object.

Method Description

GetAndLock

Returns and locks the cached object (if present). Other GetAndLock method calls on the same object fail as long as the lock is valid. Regular Get method calls are not blocked and always access the latest version of the cached object.

PutAndUnlock

Updates the locked object and then releases the lock. The lock handle obtained from GetAndLock is a required parameter and must match the lock handle of the locked object to succeed.

Unlock

Explicitly unlocks a cached object, provided that the lock handle parameter matches that of the locked object. Unlock also supports extending the expiration of the current item to help prevent it from expiring as soon as it is unlocked (if it is unlocked past its expiration time).

See Also

Concepts

Class Overview (Velocity)
Basic Cache Methods (Velocity)
Tag-Based Methods (Velocity)
Configuration Methods (Velocity)

Other Resources

Using Basic Cache Methods (Velocity)
Cache Concepts (Velocity)