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.
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
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.