The configuration for a distributed store consists of a set of .xml and .properties files. Each distributed store in a project has the following files:

A distributed store is configured using a bean element in the Spring XML configuration file. The bean element has the following attributes:

When the correlator is started with the --distMemStoreConfig dir option (see also Starting the correlator), it loads all XML files matching *-spring.xml in the specified configuration directory, and also all *-spring.properties files in the same directory. (Note, the correlator does not start unless the specified directory contains at least one configuration file.)

When using Software AG Designer, these files are generated automatically. New storeName-spring.xml and storeName-spring.properties files are created when a store is added to a project. The most commonly used settings can be changed at any time using the Distributed MemoryStore editor (which rewrites the .properties file whenever the configuration is changed). In addition, the storeName-spring.xml files can be edited manually in Software AG Designer to customize more advanced configuration aspects. To edit the XML file, open the Distributed MemoryStore editor and in the Configuration files section, click the name of the file to open it in the appropriate editor. Once the editor for an XML file has been opened, you can switch between different views using the Design and Source tabs at the bottom of the editor window.

Some property values usually need to be changed when a development and testing configuration is deployed to a different environment such as one for production use. For more information on modifying property values when moving from a test environment to a production environment, see Changing bean property values when deploying projects.

Making use of substitution variables is the best way to maintain different bean property values in different environments, as you can use the same XML file, with a different .properties file for each environment. For more details on using substitution variables to specify configuration properties, see Substitution variables.

The configuration files for a distributed store use the Spring XML file format, which provides an open-source framework for flexibly wiring together the different parts of an application, each of which is represented by a bean. Each bean is configured with an associated set of properties, and has a unique identifier which can be specified using the id attribute.

It is not necessary to have a detailed knowledge of Spring to configure a distributed store, but you may wish to explore the Spring 3.0.5 documentation to obtain a deeper understanding of what is going on and to leverage some of the more advanced functionality that Spring provides.

The Apama distributed MemoryStore configuration loads any bean that extends the Apama AbstractStoreFactory class.

Most bean properties have primitive values (such as string, number, boolean) which are set like this:

However, it is also possible to have properties that reference other beans, such as a configuration bean defined by the third-party distributed cache provider. These property values can be set by specifying the id of a top-level bean as in the following example (where it is assumed that myConfig is the id of a bean defined somewhere in the file):

Any top-level bean may be referenced in this way, that is, any bean that is a child of the <beans> element and not nested inside another bean. Referencing a bean that is defined in a different configuration file is supported.

Instead of referencing a shared bean, it is also possible to configure a bean property by creating an inner configuration bean nested inside the property value like this:

Note, advanced users may want to exploit Spring's property inheritance by using the parent attribute on an inner bean to inherit most properties from a standard top-level bean while overriding some specific subset of properties or by type-based auto-wiring.

You can use the Spring syntax for compound property names to set the value of a property held by another property. For example, to set a property stringProp on a bean held by the property beanProp, use the following:

Or, to set the value of the key myKey in a property that holds a Map called mapProp, use the following:

Substitution variables in the form ${varname} can be used to specify bean property values. Instead of specifying bean property values directly in an XML configuration file, you use ${varname} substitution variables in the XML file and specify the values of those variables in a .properties file inside the configuration directory. This makes it possible to edit the variable values in Software AG Designer and to use different values during deployment to a production environment using the Apama Ant macros.

Although .properties and storeName-spring.xml files often have similar names, there is no explicit link between them, so any properties file can define properties for use by any storeName-spring.xml file. Although in some cases it may be useful to share a single substitution variable across multiple XML files, this is not normally the desired behavior, and therefore the recommendation is that all properties follow the naming convention ${varname.storeName}.

In addition to the standard substitution variables shared by most drivers, you can add your own substitution variables for important or frequently changed properties specific to the driver specific to the cache integrated with your application. This is especially important when changing from a development environment to a production environment.

It is also possible to provide property values at runtime as Java system properties, such as specifying -J-Dvarname=value on the correlator command line.

The special variables ${APAMA_HOME} and ${APAMA_WORK} are always available.

Substitution variables are evaluated recursively. So a substitution variable can refer to another substitution variable, for example, classpath=${installDir}/foo.jar.