# System Administrator’s Guide

# Managing and Configuring the Storage Service

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.

Table 14-1outlines the store types.

Table 14-1 Store types
Type | Description
--- | ---
Cluster cache | 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

Managed object: Container ServicesStorageService

MBean: com.bea.wlcp.wlng.storage.management.StorageServiceMBean

Below is a list of attributes and operations for configuration and maintenance:

- Attribute: Active (r)
- Operation: getProviderName
- Operation: getStoreSize
- Operation: getTableName
- Operation: getTypeId
- Operation: listStoreNames

### Attribute: Active (r)

Scope: Cluster

Read-only.

Unit: n/a

Format: Boolean

Indicates whether storage service is active or not:

- true if active
- false if inactive

### Operation: getProviderName

Scope: Cluster

Gets the storage provider name for a given store.

Signature:

`getProviderName(StoreName: String)`

Table 14-2 getProviderName
getProviderName
Parameter | Description
--- | ---
StoreName | The name of the store as specified in the store configuration file.

### Operation: getStoreSize

Scope: Cluster

Gets the size of a given store. The size is number of entries.

Signature:

`getStoreSize(StoreName: String)`

Table 14-3 getStoreSize
getStoreSize
Parameter | Description
--- | ---
StoreName | The name of the store as specified in the store configuration file.

### Operation: getTableName

Scope: Cluster

Gets the name of the database table that the store maps to, if any.

Signature:

`getTableName(StoreName: String)`

Table 14-4 getTableName
getTableName
Parameter | Description
--- | ---
StoreName | The name of the store as specified in the store configuration file.

### Operation: getTypeId

Scope: Cluster

Gets the type ID of the store.

Signature:

`getTypeId(StoreName: String)`

Table 14-5 getTypeId
getTypeId
Parameter | Description
--- | ---
StoreName | The name of the store as specified in the store configuration file.

### Operation: listStoreNames

Scope: Cluster

Displays a list configured store names.

Signature:

`listStoreNames()`

Table 14-6 listStoreNames
listStoreNames
Parameter | Description
--- | ---
- | -