Program guide > Performance considerations
Locking performance best practices
Locking strategies and transaction isolation settings affect the performance of the applications.
Retrieve a cached instance
For more information, see Map entry locking:
Pessimistic locking strategy
Use the pessimistic locking strategy for read and write map operations where keys often collide. The pessimistic locking strategy has the greatest impact on performance.
Read committed and read uncommitted transaction isolation
When you are using pessimistic locking strategy, set the transaction isolation level using the Session.setTransactionIsolation method. For read committed or read uncommitted isolation, use the Session.TRANSACTION_READ_COMMITTED or Session.TRANSACTION_READ_UNCOMMITTED arguments depending on the isolation.
To reset the transaction isolation level to the default pessimistic locking behavior, use the Session.setTransactionIsolation method with the Session.REPEATABLE_READ argument.
Read committed isolation reduces the duration of shared locks, which can improve concurrency and reduce the chance for deadlocks. This isolation level should be used when a transaction does not need assurances that read values remain unchanged for the duration of the transaction.
Use an uncommitted read when the transaction does not need to see the committed data.
Optimistic locking strategy
Optimistic locking is the default configuration. This strategy improves both performance and scalability compared to the pessimistic strategy. Use this strategy when the applications can tolerate some optimistic update failures, while still performing better than the pessimistic strategy. This strategy is excellent for read operations and infrequent update applications.
The optimistic locking strategy makes a copy of the cache entries and compares them as needed. This operation can be expensive because copying the entry might involve cloning or serialization. To implement the fastest possible performance, implement the custom plug-in for non-entity maps.
See OptimisticCallback plug-in for more information.
Use version fields for entities
When you are using optimistic locking with entities, use the @Version annotation or the equivalent attribute in the Entity metadata descriptor file. The version annotation gives the ObjectGrid a very efficient way of tracking the version of an object. If the entity does not have a version field and optimistic locking is used for the entity, then the entire entity must be copied and compared.
None locking strategy
Use the none locking strategy for applications that are read only. The none locking strategy does not obtain any locks or use a lock manager. Therefore, this strategy offers the most concurrency, performance and scalability.
Parent topic:Use locking
Parent topic:Performance considerations for application developers
Map entry locks with query and indexes
CopyMode best practices
Byte array maps
Plug-in evictor performance best practices
ObjectTransformer interface best practices
Query performance tuning
Implement exception handling in locking scenarios
Configure a locking strategy
Configure the lock timeout value