Skip to content

6. Appendix A - Storage Models

As of Blitz 2.0, it is possible to configure a number of different persistence profiles. They are currently:

  1. Persistent - In this mode, Blitz behaves like a fully persistent JavaSpace such as the persistent version of Outrigger.
  2. Transient - (default setting) causes Blitz to act like a disk-backed cache. In this mode, Blitz behaves like the transient version of Outrigger. No logging is performed and, when Blitz is restarted, all state (including Join state etc.) is lost. Memory-only transient implementations can halt with OutOfMemoryError's if they are over-filled. Blitz avoids this problem by swapping to disk when the number of stored Entry's overflows it's available cache space. Obviously, performance will degrade relative to the amount of swapping Blitz is required to perform. When the caches are sufficiently large, Blitz will make minimal use of disk, yielding maximal performance.
  3. TimeBarrierPersistent - provides a performance versus persistence QoS tradeoff. In this mode, changes made more than a certain number of milliseconds ago are guarenteed to be persistent. More recent changes are not guarenteed persistent but may be persistent. This mode provides the developer with a means of balancing persistence needs against performance.

The actual model used is determined by the value of the configuration variable storageModel. The standard configuration file contains example settings for all three modes which should provide reasonable starting points for more precise tuning. For more details on the exact settings for each model see the Javadoc for org.dancres.blitz.config.Persistent, org.dancres.blitz.config.Transient and org.dancres.blitz.config.TimeBarrierPersistent.