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 |
|---|---|
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. |
|
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. |
|
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. |
|
Does not have any optimistic currency-related overloads. Add either succeeds or fails. |
|
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. |
|
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 |
|---|---|
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. |
|
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. |
|
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)