Administration guide > Configure the deployment environment > Configuring data grids
Configure write-behind loader support
You can enable write-behind support either using the ObjectGrid descriptor XML file or programmatically using the BackingMap interface.
Use either the ObjectGrid descriptor XML file to enable write-behind support, or programmatically by using the BackingMap interface.
ObjectGrid descriptor XML file
When configuring an ObjectGrid using an ObjectGrid descriptor XML file, the write-behind loader is enabled by setting the writeBehind attribute on the backingMap tag. An example follows:
<objectGrid name="library" > <backingMap name="book" writeBehind="T300;C900" pluginCollectionRef="bookPlugins"/>
In the previous example, write-behind support of the book backing map is enabled with parameter T300;C900. The write-behind attribute specifies the maximum update time and/or a maximum key update count. The format of the write-behind parameter is:
::= <defaults> | <update time> | <update key count> | <update time> ";" <update key count>::= "T" <positive integer>::= "C" <positive integer>::= ""
- write-behind attribute
- update time
- update key count
- defaults
Updates to the loader occur when one of the following events occurs:
- The maximum update time in seconds has elapsed since the last update.
- The number of updated keys in the queue map has reached the update key count.
These parameters are just hints. The real update count and update time will be within close range of the parameters. However, we do not guarantee that the actual update count or update time are the same as defined in the parameters. Also, the first behind update could happen after up to twice as long as the update time. This is because ObjectGrid randomizes the update starting time so all partitions will not hit the database simultaneously.
In the previous example T300;C900, the loader writes the data to the back-end when 300 seconds have passed since the last update or when 900 keys are pending to be updated. The default update time is 300 seconds and the default update key count is 1000.
- Write-behind caching
Use write-behind caching to reduce the overhead that occurs when updating a database you are using as a back end.
- Write-behind caching support
Use write-behind caching to reduce the overhead that occurs when updating a back-end database. Write-behind caching queues updates to the Loader plug-in.
- Handle failed write-behind updates
Since the WebSphere eXtreme Scale transaction finishes before the back-end transaction starts, it is possible to have transaction false success.
- Example: Writing a write-behind dumper class
This sample source code shows how to write a watcher (dumper) to handle failed write-behind updates.
Parent topic:
Configure data grids
Related concepts
Plug-ins for communicating with persistent stores
Related tasks
Configure peer-to-peer replication with JMS
Related reference
ObjectGrid descriptor XML file