Configuring the object grid to persist data

Use a persistence template file, or uncomment the persistence entry for each map, to configure your chosen persistence policy. You must then set the preload parameter in the default object grid file.

About this task

The persistence policy write-through (synchronous) or write-behind (asynchronous) determines when to write state changes to the database.

Asynchronous write-behind is better for performance. Because of the in-memory redundancy, data integrity is not an issue with a write-behind policy, except when the DBMS becomes inaccessible. If a DBMS becomes inaccessible, shut off inbound events before you shut down the entire cluster.

In a low-volume non-high availability (HA) topology, or if you are concerned about whole-site loss, you can remove the writeBehind parameter and keep the backing database synchronously up-to-date.

Warning: Data can be lost if the DBMS becomes inaccessible with write-behind persistence, as the data that is left in memory cannot be written. Inaccessibility is not an issue if you use a DBMS that is HA.

Templates for each persistence strategy can be found in the following locations:

<InstallDir>/runtime/ia/persistence/grids/write-through/objectgrid.xml
<InstallDir>/runtime/ia/persistence/grids/write-behind/objectgrid.xml

If you do not want to use one of the templates that are provided, uncomment all instances of the Loader declaration in the default object grid file. The following procedure shows how to uncomment and fine-tune the write-behind persistence of data in the objectgrid.xml file.

Procedure

Open the <WLP_USER_DIR>/servers/your_runtime_server_name/grids/objectgrid.xml file of the runtime servers.
Find the <objectGrid name="com.ibm.ia"> line and change initialState="ONLINE" to initialState="PRELOAD".
PRELOAD instructs the object grid to pause before it enters the online state, which gives you the opportunity to recover data during disaster recovery.

Uncomment the following line in all the map blocks:

<!-- <bean id="Loader" osgiService="CISSQLManager"/> -->

For example, the following EntityPlugins map collection shows persistence that is enabled.

<backingMapPluginCollection id="EntityPlugins">
   <bean id="Loader" osgiService="CISSQLManager"/>
</backingMapPluginCollection>

Optional: Identify which maps require asynchronous persistence.
1. In the objectgrid.xml file, alter the backingMap definition of these maps to include the writeBehind element.
2. Enter a value (T) for the maximum time interval between committing changes to the database, and a value (C) for the maximum number of changes between commits to the database.
  The higher the numbers, the less frequent the changes are committed to the database. Choose values that specify the minimum amount of information that can be lost in a full system outage.
  The following example shows a backing map for entities with the write-behind values of T20 and C200.
```
<backingMap name="Entity.*" template="true" lockStrategy="PESSIMISTIC" copyMode="COPY_TO_BYTES" pluginCollectionRef="EntityPlugins" writeBehind="T20;C200" />
```
  Twenty seconds can pass before changes are written, and 200 changes can occur before changes are written to the database.

What to do next

After the object grid file is updated, and you start the runtime and catalog servers in your topology, the grid is in a state of PRELOAD. To ready the object grid to accept events, you must run the dataLoadManager finalize command. This step is marked as an option when you start the cloned servers.