Overview

In the pessimistic locking approach, your program must explicitly obtain a lock using transaction on one or more objects before making any changes. This prevents any other user from making changes to those objects, so you can be sure that committing the operation will succeed. Once changes are completed, the objects are unlocked so that others can make changes to them.

In the context of the cache, this means you cannot have multiple users performing read, take or update operations with the same UID or matching objects under a transaction. In general an update operation that is using a transaction must wait for all other users to commit or rollback their transactions, and only then can it be completed successfully.
When performing read operations without using transaction, users can immediately perform an update operation, without having to wait for other users to complete their transaction (since there is none). However, there is no guarantee that the update operation will be performed on the latest version of the object.
Pessimistic locking decreases concurrency because objects are tied up for longer periods. Locking objects also imposes more work on the space server. When there is a conflict, users have to "get in line" to wait for an object to become unlocked. These users may, themselves, already have other objects locked up while they're waiting. If any of these objects needed by a user are farther ahead in line, then you will have a "deadlock," which can be difficult to manage.