The following section describes how to configure and manage the Storage Service.
Introduction to the Storage Service
The Storage Service provides transparent data access to communication services and container services. Conceptually, a module uses the Storage Service, which uses one or more underlying storage providers that define how and where data is stored. A module creates and uses one or more named stores which can be of different store types. The current storage provider is the Invalidating Storage Provider, an in-memory cache backed by a persistence store, currently a database, acting as the master. The store is a write-through cache. In order to maintain a coherent view of the cache, invalidating events are broadcast within the cluster for specific operations.
A cluster wide in memory only store, ideally with redundancy support by keeping backup copies on one or more of the other servers in the cluster. As this is an in memory only store, data reads/writes are very fast.
Write behind database store
A cluster wide in memory cache, ideally with redundancy support by keeping backup copies on one or more of the other server in the cluster, and also backed by a database. Updates for the database table for write behind stores are delayed and asynchronously written in batches to the database.
This store has similar performance characteristics as the cluster store for data that is available in the cache, but with better availability.
Write through database store
Similar to write behind data store, this is a cluster wide in memory cache of a database table. Updates for the database table for write through stores are done synchronously as part of the store update operation.
Updates to data in the store will be slow compared to cluster store, but read operations will be fast if the data is available in cache. This store offers best reliability.
Database log store
Similar to write behind data store, the log store type data updates to the database table are delayed and asynchronously written in batches to the database.
This type of store is meant for additive batch writing of write only data. Since this type of store is not meant for reading, updating or deleting data, it does not need to keep a cache.
Since this store is only meant for adding data, read performance will be poor, but optimized for add operations by doing database writes in batches.
Note:
The only store type used in this release is the Write through database store.
Each communication service has it’s own store definition in the directory
$DOMAIN_HOME/config/store_schema
The store definitions are JAR files with a configuration file and class definitions for the stored data.
Reference: Attributes and Operations for Storage Service
StorageService
