The following section describes how to configure and manage 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.
Table 14-1outlines the store types.
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.
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.
|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
The store definitions are JAR files with a configuration file and class definitions for the stored data.
Managed object: Container ServicesStorageService
Below is a list of attributes and operations for configuration and maintenance:
Indicates whether storage service is active or not:
Gets the storage provider name for a given store.
Gets the size of a given store. The size is number of entries.
Gets the name of the database table that the store maps to, if any.
Gets the type ID of the store.
Displays a list configured store names.