BigMemory Max 4.3.5 | Product Documentation | BigMemory Max Configuration Guide | Configuring Fast Restart (FRS) | Data Persistence Implementation
 
Data Persistence Implementation
The BigMemory Fast Restart feature works by creating a real-time record of the in-memory data, which it persists in a Fast Restart store on the local disk. After any restart, the data that was last in memory (both heap and off-heap stores) automatically loads from the Fast Restart store back into memory.
Data persistence is configured by adding the <persistence> sub-element to a cache configuration. The <persistence> sub-element includes two attributes: strategy and synchronousWrites.
<cache>
<persistence strategy="localRestartable|localTempSwap|none|distributed"
synchronousWrites="false|true"/>
</cache>
Strategy Options
The options for the strategy attribute are:
*"localRestartable" — Enables the Fast Restart feature which automatically logs all BigMemory data. This option provides fast restartability with fault-tolerant data persistence.
*"localTempSwap" — Enables temporary local disk usage. This option provides an extra tier for data storage during operation, but this store is not persisted. After a restart, the disk is cleared of any BigMemory data.
*"none" — Does not offload data to disk. With this option, all of the working data is kept in memory only. This is the default mode.
*
*"distributed" — Defers to the <terracotta> configuration for persistence settings. For more information, refer to Terracotta Clustering Configuration Elements.
Synchronous Writes Options
If the strategy attribute is set to "localRestartable", then the synchronousWrites attribute can be configured. The options for synchronousWrites are:
*synchronousWrites="false" — This option specifies that an eventually consistent record of the data is kept on disk at all times. Writes to disk happen when efficient, and cache operations proceed without waiting for acknowledgement of writing to disk. After a restart, the data is recovered as it was when last synced. This option is faster than synchronousWrites="true", but after a crash, the last 2-3 seconds of written data may be lost.
If not specified, the default for synchronousWrites is "false".
*synchronousWrites="true" — This option specifies that a fully consistent record of the data is kept on disk at all times. As changes are made to the data set, they are synchronously recorded on disk. The write to disk happens before a return to the caller. After a restart, the data is recovered exactly as it was before shutdown. This option is slower than synchronousWrites="false", but after a crash, it provides full data consistency.
For transaction caching with synchronousWrites, soft locks are used to protect access. If there is a crash in the middle of a transaction, then upon recovery the soft locks are cleared on next access.
Note: The synchronousWrites attribute is also available in the <terracotta> sub-element. If configured in both places, it must have the same value.
DiskStore Path
The path to the directory where any required disk files will be created is configured with the <diskStore> sub-element of the Ehcache configuration.
*For "localRestartable", a unique and explicitly specified path is required for each node.
*For "localTempSwap", if the disk store path is not specified, a default path is used for the disk tier, and the default path will be auto-resolved in the case of a conflict with another CacheManager.
Note: The Fast Restart feature does not use the disk tier in the same way that conventional disk persistence does. Therefore, when configured for "localRestartable," disk store size measures such as Cache.getDiskStoreSize() or Cache.calculateOnDiskSize() are not applicable and will return zero. On the other hand, when configured for "localTempSwap", these measures will return size values.

Copyright © 2010 - 2019 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.
Innovation Release