Export (0) Print
Expand All
1 out of 1 rated this helpful - Rate this topic

Concurrency Methods (Windows Server AppFabric Caching)

Windows Server AppFabric caching 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 (Windows Server AppFabric Caching).

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 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 concurrency-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 Concurrency Model

In the pessimistic concurrency 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, time-outs 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.

noteNote
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.

WarningWarning
Locked objects in the cache can still be replaced by any cache client with the Put method. Cache-enabled applications are responsible for consistently using PutAndUnlock for items that use the pessimistic concurrency model.

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

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.