Shared All Persistence

Because ActiveSpaces is a true peer-to-peer distributed system, it provides API operations that let you enable shared all persistence. With shared all persistence, some of the space members — the persisters — are responsible for interacting with a persistence layer, just as some of the space members — the seeders — provide the basic space service.

Applications can register their ability to provide the persistence service on a space by invoking the setPersister method of the Space object. In Java, this method takes an instance of a class that implements the Persister interface. In C it takes a tibasPersister object, which itself can be created using the tibasPersister_Create function where pointers to the functions required by the persister interface are provided by the user. It is therefore necessary for the application to first have joined the space (as a seeder or as a leech) before it can register itself as a persister.

Applications can also indicate their desire to stop providing the persistence service by invoking the space's stopPersister method in Java and tibasPersister_Free in C.

Interaction with the persistence layer is implemented by classes (or sets of functions in C) that implement the Persister interface. It is up to the user to provide implementations of this interface to perform persistence to their persistent storage of choice (for example a database, or a key-value store, or a file system).

Applications able to provide the persistence service register an instance of a class implementing the Persister interface for a space using the space object's setPersister method, and indicate their willingness to stop providing the persistence service for a space using the space object's stopPersister method.

The Persister interface consists of five methods:

  • onOpen
     Invoked when the persister object is registered with the space
  • onClose
     Invoked when the persister object is stopped for the space
  • onWrite
     Invoked when a tuple stored in the space is modified (due to a put, take, or update operation) and is intended to perform the steps necessary to reflect the change in the space onto the persistence layer.
  • onRead
     Invoked if the space has a capacity set and a capacity policy of EVICT, and if a request to read, lock, or take a tuple by key value did not result in a matching tuple being found in the space.
  • onLoad
     The onLoad callback is made to the first persister instance.

It is invoked as soon as the space has reached the minimum number of seeders. If the space has a capacity set and a capacity policy of EVICT it is not required to do anything but can still be used to pre-load the caching space with some of the tuples stored in the persistence layer.
Related concepts