WebSphere eXtreme Scale Best Practices for Operation and Management

Chapter 6. Performance planning for application developers 123

Locks are held only for a short duration while data is being read from the cache and copied to

the transaction. When the transaction cache is synchronized with the main cache, any cache

objects that have been updated are checked against the original version. If the check fails, the

transaction is rolled back, and an OptimisticCollisionException results.

6.3.3 None locking strategy

Use the none locking strategy for applications that are read only. The none locking strategy

does not obtain any locks. Therefore, it offers the most concurrency, performance, and

scalability. The none lock strategy is ideal for look-up tables or read-only maps.

6.3.4 Lock semantics for lockStrategy=PESSIMISTIC, OPTMISTIC, and NONE

This material is based on the “Locking Strategy” and “Handling locks” sections of the

WebSphere eXtreme Scale V7.1 Programming Guide. It applies to WebSphere eXtreme

Scale V7.0 and 6.1, as well. Readers with knowledge of database locking semantics will find

this material familiar.

An underlying principle that applies to all three strategies is that there are three lock modes,

and each mode, when already held, allows or refuses requests for the other types in a certain

way. The three lock modes are a property of an individual object that is stored in a

BackingMap and, to an extent, each transaction. Any transaction at any point in time might

not hold a lock of a given mode on a given object. Each object in the map is separately locked

in one of the three ways (or no way) by a given transaction at any moment in time.

We describe the three lock modes and their behavior:

򐂰 S lock (shared lock): If a transaction holds an S lock on an object, other transactions can

obtain an S lock or U lock on that object, but not an X lock on the object.

򐂰 U lock (upgradable lock): If a transaction holds a U lock on an object, other transactions

can obtain an S lock on that object, but not a U lock or an X lock.

򐂰 X lock (exclusive lock): If a transaction holds an X lock on an object, other transactions

cannot obtain an S lock, U lock, or X lock on that object.

There is also, of course, the state of no lock at all being held by a transaction for an object.

Another way to express these behaviors, somewhat more mathematically, is that the state of

locks on a given object can only be:

(0-to-N S locks AND 0-to-1 U lock) OR 0-to-1 X lock

The locking behavior described here assumes that your transaction isolation setting is the

default of repeatable read. You can change your transaction isolation to read committed or

read uncommitted, which will modify the locking behavior of each lockingStrategy choice.

Another interesting thing to note is that you can lock an object, which is not (yet or ever) in the

grid. You only need a valid key. If you call myMap.getForUpdate(someKey) and no such object

exists (it returns null), you will then hold whatever lock you might have held if there had been

an entry for that key. That lock will be freed in the same manner as if there had been an entry

with that key. If another transaction tries to access that map with that key, you will have the

same sort of lock conflict (or lack of conflict) as if there had been an entry. If the other

transaction inserts an object into the map with that key, it will succeed or fail based on lock

conflict rules in the same way. This function can be useful if you need to use locks to ensure

only one transaction (that is, one thread) out of many transactions actually goes off to a