Distributed stores make use of Java Distributed cache technologies (the specific technologies depend on the driver you select). When you start a correlator with the --distMemStoreConfig option (enabled automatically if you use Apama Studio to add a Distributed Memory store configuration to your project), the correlator automatically starts with an embedded Java virtual machine. This JVM is shared by any Apama applications using a Distributed MemoryStore or Correlator-integrated JMS and any Apama Java applications.

A distributed store is defined by a bean in a Spring XML configuration file. The bean specifies the properties that configure the distributed store and the bean's name, which is the name of the store. When an Apama application prepares a distributed store, using the prepareDistributed() action, it supplies the name of the bean. For more information on properties used in the configuration file, see Configuring a distributed store and Configuration files for distributed stores.

Depending on the distributed cache provider you select, the data may be stored in the Java heap. If so, you may need to set an appropriate size for the Java heap, for example, by specifying -J-Xmx2048M (to specify a 2GB heap) on the command line that starts the correlator. If you are using BigMemory Max off-heap data, you may need to supply a -J-XX:MaxDirectoryMemorySize= command line argument as well. For details, see http://terracotta.org/documentation/4.0/bigmemorymax/get-started/quick-start. JVM options must be placed on the correlator command line and prefixed with -J. In Apama Studio, this can be configured by opening the project's launch configuration, editing the properties of the Correlator component and selecting the Maximum java off-heap storage in Mb option. See Correlator arguments.

The main steps in configuring a distributed store are:

A cluster name should be provided when opening a distributed store. Some third-party drivers and distributed caches use the cluster name as an identifier, that is, they do not interpret the name in any way. Many distributed caches use broadcast or multicast to automatically discover other cluster nodes on the same network with the same name configured. Thus, during development and testing, a name that is different to the name used by your production system should be used. This is a good practice to follow even if the systems are on separate networks. Cluster names are specified in properties files, which should be different between development and production environments.

You should not create more than one store with the same cluster name on any one correlator.