Optimistic Concurrency Model in Velocity

To mitigate security risks, all cache clients, cache servers, and the primary data source server should be members of the same corporate domain, and should be deployed within the perimeter of the corporate firewall. It is also highly recommended to secure your application configuration files on the cache clients.

To help your application deal with concurrency issues, "Velocity" supports optimistic and pessimistic concurrency models. For information about the methods available to align to these models, see Concurrency Methods (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 then sends that version information together with the updated object to the cache for an update. The system only updates the object if the version sent matches the current version of the object. Every update to an object changes its version number, which prevents the update from overwriting someone else’s changes.

The example in this topic illustrates how optimistic concurrency maintains data consistency.

Example
In this example, two cache clients (cacheClientA and cacheClientB) on two separate application servers try to update the same cached object, which is named RadioInventory.

Time Zero: Both Clients Retrieve the Same Object
At time zero (T0), both cache clients instantiate a DataCacheItem class to capture the cached object that they intend to update, together with additional information associated with that cached object, such as version and tag information. This is illustrated in the following diagram and code example.