When an item type’s caching mode is set to locked, the repository must obtain read or write locks to items before it can make them accessible to an application. Items that use locked caching mode can have one writer or multiple readers at a time.
Write lock request
When an application updates an item, the item’s repository requests a write lock from its ClientLockManager. If another transaction on the same ATG instance owns a write lock on the same item, the ClientLockManager can transfer the write lock, when available, to the pending request. Otherwise, it relays the request to its ServerLockManager, which determines whether it has any lock entries for the item. The ServerLockManager then processes the lock request as follows:
Existing lock entry | ServerLockManager action |
---|---|
None | Grants write lock request, creates write lock entry for the item. |
Read | Asks ClientLockManagers to release their read locks on the item. When all read locks are released, grants the write lock request and creates a write lock entry for the item. |
Write | Denies write lock request and adds the request to the queue of other pending requests for the item. Grants the request when the item becomes available. Note: A write lock request always has precedence over pending read lock requests. |
Read lock request
When an application looks up an item, the item’s repository requests a read lock from its ClientLockManager. The ClientLockManager relays this request to its ServerLockManager, which determines whether it already has any lock entries for the item. It then processes the lock request as follows:
Existing lock entry | ServerLockManager action |
---|---|
None | Grants read lock, creates read lock entry for the item. |
Read | Grants read lock, adds this ClientLockManager to list of read locks for the item. |
Write | Denies read lock and adds the read lock request to the queue of other pending read requests for the item. Grants the request when the item becomes available. |
Processing competing lock requests
When a transaction releases a write lock and multiple lock requests are pending for the locked item, the requests are processed in the following order:
If any write lock requests are pending on the local ATG instance for the item, the ClientLockManager transfers the write lock to one of them.
If no write lock requests are pending locally for the item, the ClientLockManager checks whether any lock requests are pending on other ATG instances; if so, it releases the lock to the ServerLockManager so it can grant one of those requests.
If no remote lock requests are pending, the ClientLockManager checks whether any local read lock requests are pending; if so, it releases the write lock and grants one of those requests.
Lock lifespan
Lock ownership information is cached on the ClientLockManager as long as the item itself remains in the item cache. The lock can be passed among different transactions or threads on the ATG instance without informing the ServerLockManager.
A read lock remains valid until one of the following events occurs:
The item is removed from the item cache—for example, the item exceeded its
itemcachetimeout
setting.The ServerLockManager requests that the lock be released—for example, in response to a write lock request.