WebSphere eXtreme Scale Administration Guide > Configure WebSphere eXtreme Scale



Map entry locking


An ObjectGrid BackingMap supports several locking strategies for maps to maintain cache entry consistency.

Each BackingMap can be configured to use one of the following locking strategies:

  1. Optimistic locking mode

  2. Pessimistic locking mode

  3. None

The default lock strategy is OPTIMISTIC. Use optimistic locking when data is changed infrequently. Locks are only held 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, then the transaction is rolled back and an OptimisticCollisionException exception results.

The PESSIMISTIC lock strategy acquires locks for cache entries and should be used when data is changed frequently. Any time a cache entry is read, a lock is acquired and conditionally held until the transaction completes. The duration of some locks can be tuned using transaction isolation levels for the session.

If locking is not required because the data is never updated or is only updated during quiet periods, you can disable locking by using the NONE lock strategy. This strategy is very fast because a lock manager is not required. The NONE lock strategy is ideal for look-up tables or read-only maps. For more information about locking strategies, see Locking strategies .


Specify a lock strategy

The following example demonstrates how the lock strategy can be set on the map1, map2, and map3 BackingMaps, where each map is using a different locking strategy. The first snippet shows how to use XML for lock strategy configuration and the second snippet shows a programmatic approach.


XML approach 

BackMap configuration - XML example
<?xml version="1.0" encoding="UTF-8"?>
<objectGridConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://ibm.com/ws/objectgrid/config ../objectGrid.xsd"
    xmlns="http://ibm.com/ws/objectgrid/config">

   
<objectGrids>
       
<objectGrid name="test">
           
<backingMap name="map1"
                lockStrategy="PESSIMISTIC" numberOfLockBuckets="31"/>
           
<backingMap name="map2"
                lockStrategy="OPTIMISTIC" numberOfLockBuckets="409"/>
           
<backingMap name="map3"
                lockStrategy="NONE"/>
       
</objectGrid>
   
</objectGrids>
</objectGridConfig>


Programmatic approach 

BackMap configuration - programmatic example
import com.ibm.websphere.objectgrid.BackingMap;
import com.ibm.websphere.objectgrid.LockStrategy;
import com.ibm.websphere.objectgrid.ObjectGrid;
import com.ibm.websphere.objectgrid.ObjectGridManagerFactory;
...
ObjectGrid og = 
    ObjectGridManagerFactory.getObjectGridManager().createObjectGrid("test");
BackingMap bm = og.defineMap("map1");
bm.setLockStrategy( LockStrategy.PESSIMISTIC );
bm.setNumberOfLockBuckets(31);
bm = og.defineMap("map2");
bm.setNumberOfLockBuckets(409);
bm.setLockStrategy( LockStrategy.OPTIMISTIC );
bm = og.defineMap("map3");
bm.setLockStrategy( LockStrategy.NONE );

To avoid a java.lang.IllegalStateException exception, the setLockStrategy method must be called before using the initialize or getSession methods on a local ObjectGrid instance.

For more information see Locking strategies.


Lock manager configuration

When either a PESSIMISTIC or an OPTIMISTIC lock strategy is used, a lock manager is created for the BackingMap. The lock manager uses a hash map to track entries that are locked by one or more transactions. If many map entries exist in the hash map, more lock buckets can result in better performance. The risk of Java™ synchronization collisions is lower as the number of buckets grows. More lock buckets also lead to more concurrency. The previous examples show how an application can set the number of lock buckets to use for a given BackingMap instance.

To avoid a java.lang.IllegalStateException exception, the setNumberOfLockBuckets method must be called before calling the initialize or getSession methods on the ObjectGrid instance. The setNumberOfLockBuckets method parameter is a Java primitive integer that specifies the number of lock buckets to use. Using a prime number can allow for a uniform distribution of map entries over the lock buckets. A good starting point for best performance is to set the number of lock buckets to about 10 percent of the expected number of BackingMap entries.


LockDeadlockException

Following is a code example that shows catching the exception, and the resulting message is then displayed. 

try {
...
} catch (ObjectGridException oe) {
System.out.println(oe);
}

The result is: 

com.ibm.websphere.objectgrid.plugins.LockDeadlockException: _Message

This message represents the string that is passed as a parameter when the exception is created and thrown.


Exception cause

The most common type of deadlock exception happens when you use the pessimistic lock strategy, and two separate clients each own a shared lock on a particular object. Then, both clients attempt to promote to an exclusive lock on that object. The following diagram illustrates such a situation, including transaction blocks that cause the exception to be thrown.

The following Java code snippet demonstrates how to pass in an XML configuration file to create an ObjectGrid.

This is an abstract view of what is occurring in the program when the exception occurs. In an application with many threads updating the same ObjectMap, it is possible to encounter this situation. The following is an example of two clients executing the transaction code blocks, as illustrated in the previous figure.


Possible solutions

You can possibly encounter the situation illustrated in Figure 1 when numerous threads start transactions on a particular map. In this case, the exception is thrown to keep the program from hanging. You can notify yourself, and add code to the catch block for more details on the cause. Since you only see this exception in a pessimistic locking strategy, one simple solution is to simply use an optimistic locking strategy. If you require a pessimistic locking strategy, however, you can use the getForUpdate method instead of the get method. This eliminates receiving the exceptions for the situation described previously.



Parent topic

Configure WebSphere eXtreme Scale


+

Search Tips   |   Advanced Search