For some item descriptors, it may be most efficient to use read and write locks to manage access to your data. At any given time, you can have one server that is caching or modifying an item (or no servers modifying the item and zero or more servers caching the item, for read-only access). This avoids the need for you to broadcast cache invalidation events to all servers each time you make a change to the item. Locked mode may be the best choice for item types that are modified frequently during runtime. It also does the best job of guaranteeing that only up-to-date data is seen by your application.
If an item uses locked mode caching, then the repository consults a central lock server to obtain read or write access for the item. The lock server allows multiple simultaneous readers, but only a single writer. Lock ownership (either read or write) is cached on the server that last requested that type of access to that item. As soon as another server requests a write lock for that item, all servers which currently have ownership are asked to give up lock ownership as soon as all transactions which own that lock release it.
When you set the cache-mode attribute to locked in a repository, ATG uses read and write locks to control which threads can access an item. (Read locks are also called “shared locks” and write locks are called “exclusive locks.”) The exact behavior depends on how you set the isolation level for the item descriptor.
