15 Managing and Configuring the Storage Service

This chapter 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 15-1 outlines the store types.

Table 15-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. Because 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 implemented by keeping backup copies on one or more of the other servers 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 to the cluster store for data that is available in the cache, but with better availability.
Write through database store	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 the cluster store, but read operations will be fast if the data is available in cache. This store offers best reliability.
Database log 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. Because this type of store is not meant for reading, updating or deleting data, it does not need to keep a cache. Because this store is meant only for adding data, read performance is poor, but it is optimized for add operations by performing database writes in batches.

Each communication service has its 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.

Storage Data Expiration

To prevent the databases underlying the Storage service from growing too large, data in the Storage service can be set to expire, after which time the data is deleted. One of the visible consequences of this is that the status of delivery receipt can be unsuccessful if an old message is deleted from storage because it aged beyond the configured expiration period.

You can configure both the data expiration period for a communication service and the interval that Services Gatekeeper checks whether data in the stores has expired.

Configuring the Expiration Period

To set the data expiration period:

Locate the store schema JAR file for the store that you want to configure.

In Services Gatekeeper 5.1, these jar files are in under the Domain_Home/config/store_schema directory.

For example, the JAR file for the common smpp store is Domain_Home/config/store_schema/com.bea.wlcp.wlng.sms.common.store.
Extract the files from the JAR file for the store that you want to configure.
Open the wlng-cachestore-config-extensions.xml file.
In the extensions file, create or edit the <expiry> element, setting its expiry_age value. The value is in seconds.
Save the file.

If expiry_age is not set, the data never expires.

The following example shows the configuration of the MO message store setting the expiration period to 604800 seconds (one week).

<!-- MO message store (common) start -->
  <db_table name="pl_sms_mo_sms">
    <key_column name="msg_id" data_type="VARCHAR(30)"/> 
    <bucket_column name="smsdata" data_type="BLOB"/>
 
    <value_column name="notif_correlator" data_type="VARCHAR(30)">
      <methods>
        <get_method name="getNotificationInfoCorrelator"/>
        <set_method name="setNotificationInfoCorrelator"/>
      </methods>
    </value_column>
    <expiry expiry_age="604800"/> <!-- 1 week  -->
  </db_table>

Configuring the Checking Interval

At the system level, Services Gatekeeper checks whether Storage data has expired at a set interval defined by the com.bea.wlcp.wlng.storage.expiry_period variable. The default for the expiry_period is every 1800000 milliseconds (thirty minutes).

You can configure this value on server startup by passing it as a Java option when you restart Services Gatekeeper. The option is:

JAVA_OPTIONS="${JAVA_OPTIONS} -Dcom.bea.wlcp.wlng.storage.expiry_period=expiry_period_value"

For example, the following flag configures Services Gatekeeper to check for expired data once an hour:

JAVA_OPTIONS="${JAVA_OPTIONS} -Dcom.bea.wlcp.wlng.storage.expiry_period=3600000"

Reference: Attributes and Operations for Storage Service

Managed object: Container Services−>StorageService

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

Following 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: Not applicable

Format: Boolean

Indicates whether the storage service is active:

true if active
false if inactive

Operation: getProviderName

Scope: Cluster

Gets the storage provider name for a given store.

Signature:

getProviderName(StoreName: String)

Table 15-2 describes this parameter.

Table 15-2 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 15-3 describes this parameter.

Table 15-3 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 15-4 describes this parameter.

Table 15-4 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 15-5 describes this parameter.

Table 15-5 getTypeId

Parameter	Description
StoreName	The name of the store as specified in the store configuration file.

Operation: listStoreNames

Scope: Cluster

Displays a list of configured store names.

Signature:

listStoreNames()