com.ibm.websphere.objectgrid.writebehind
Class WriteBehindLoaderConstants

java.lang.Object
  com.ibm.websphere.objectgrid.writebehind.WriteBehindLoaderConstants

public class WriteBehindLoaderConstants
extends Object

This class contains constants used for write behind loaders.

If a map is configured with write-behind loader update, the updates (could be insert type, remove type, or update type) to the backend are not instantly updated to the backend by calling the Loader.batchUpdate(TxID, LogSequence) method. Instead, they are queued in a write-behind queue map, and then updated to the backend periodically.

Since:

XD 6.1.0.3

See Also:

BackingMap.setWriteBehind(String)

Field Summary

static String

WRITE_BEHIND_FAILED_UPDATES_MAP_PREFIX A write-behind update is pushed to the backend periodically within a different transaction from the one the update is made to ObjectGrid.

Constructor Summary

WriteBehindLoaderConstants()

Method Summary

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Field Detail

WRITE_BEHIND_FAILED_UPDATES_MAP_PREFIX

public static final String WRITE_BEHIND_FAILED_UPDATES_MAP_PREFIX

A write-behind update is pushed to the backend periodically within a different transaction from the one the update is made to ObjectGrid. When the write-behind update to the backend fails, for example, due to data integrity problem, it is too late to roll back the original ObjectGrid transaction. ObjectGrid will invalidate the entry and create an entry in a failed database update map. The name of this failed database update map Map is WriteBehindLoaderConstants.WRITE_BEHIND_FAILED_UPDATES_MAP_PREFIX+baseMapName. The key of the entry in this map is an auto-increment Integer, and the value is a LogElement.

You can use Session.getMap(String) to get a reference to the failed database upate map, and then use ObjectMap.getNextKey(long) to get the next failed update and then take appropriate actions to compensate the failure.

We recommend removing the failed update from this failed database update map periodically. By default, this failed database update map is configured with a TTL evictor. The The type of the TTL evictor is TTLType.CREATION_TIME and the time-to-live is 1 hour.

For example, you configure map "payroll" as write-behind. If the write-behind updates to the database fails, all the failed database updates will be stored in the map WriteBehindLoaderConstants.WRITE_BEHIND_FAILED_UPDATES_MAP_PREFIX+"payroll".

See Also:

Constant Field Values

Constructor Detail

WriteBehindLoaderConstants

public WriteBehindLoaderConstants()