Persistence Policy and Implementation
For both types of persistence, you can specify that the persistence is maintained synchronously or asynchronously.
Shared-Nothing Persistence
With shared-nothing persistence, each node that joins a space as a seeder maintains a copy of the space data on disk.
Persisted Data Store
When you configure shared-nothing persistence, you must use a unique name for each member joining the spaces, and you must specify an existing directory path for which ActiveSpaces has read and write access.
You can specify the directory path for data storage as follows:
- Through calls to the API operations.
- For as-agents, by using the command line arguments for as-agent.
- Through an environment variable.
The directory you specify is used as the root path under which ActiveSpaces creates its own subdirectory structure, using the format metaspace/space/member.
ActiveSpaces creates and manages persistence files automatically. You do not have to provide a filename for the stored data—the data store directory is used as the location to create and use the file.
For detailed information on implementing shared-nothing persistence, see Persistence.
For detailed information on implementing shared-all persistence, see Persistence.
- Terms and Concepts for Persistence
- TIBCO ActiveSpaces Cluster Startup with Persistence
With shared-nothing persistence, when ActiveSpaces nodes are started for the first time and join the metaspace (and subsequently the defined space), ActiveSpaces creates new data store files, and since there are no old files to recover from, the space automatically enters the READY state and is available for space operations. - Space Recovery with Persistence
When you configure persistence, you have the option of configuring space recovery. - Space Resume with Shared-All Persistence
When a space loses one of its persisters, the space is set to a SUSPENDED state, which means that no writes to persistence files can happen. In this case, you can resume the space. - Space Life Cycle and Persistence
The space life cycle starts when the space is first defined in the metaspace and ends when the space definition is dropped from the metaspace. - Persistence and Space Life Cycle
When a space needs to be persistent so that the data that is stored in it does not disappear after a disaster (all seeders have crashed) or a maintenance shutdown, you should define it as a persisted space. - Write-Behind Caching
ActiveSpaces supports write-behind caching in addition to write-through caching to a back-end database. Write-behind caching provides asynchronous writes to the database for faster performance, and allows writes to be buffered in cache and written to the database later in case the database is down.