In Spring GemFire 1.1 dedicated support for configuring a CacheServer was added through the org.springframework.data.gemfire.server package allowing complete configuration through the Spring container:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:gfe="http://www.springframework.org/schema/gemfire"
	xmlns:p="http://www.springframework.org/schema/p"
	xmlns:context="http://www.springframework.org/schema/context"
	xmlns:util="http://www.springframework.org/schema/util"
	xsi:schemaLocation="http://www.springframework.org/schema/gemfire http://www.springframework.org/schema/gemfire/spring-gemfire.xsd
		http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
		http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
		http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd">

	<gfe:cache />
	
	<!-- Advanced example depicting various cache server configuration options -->
	<gfe:cache-server id="advanced-config" auto-startup="true"
		bind-address="localhost" port="${gfe.port.6}" host-name-for-clients="localhost"
		load-poll-interval="2000" max-connections="22" max-threads="16"
		max-message-count="1000" max-time-between-pings="30000"
		groups="test-server">

		<gfe:subscription-config eviction-type="ENTRY" capacity="1000" disk-store="file://${java.io.tmpdir}"/>
	</gfe:cache-server>

	<context:property-placeholder location="classpath:port.properties" />
</beans>

The configuration above shows the dedicated namespace support (through the cache-server element) and the pleothera of options available. Note that rather then just hard-coding the port, this config uses Spring util namespace to read it from a properties file and then replace it at runtime allowing administrators to change it without having to touch the main application config. Through Spring's property placeholder support, SpEL and the environment abstraction one can externalize environment specific properties from the main code base easing the deployment across multiple machines.

Note

To avoid initialization problems, the CacheServers started by SGF will start after the container has been fully initialized. This allows potential regions, listener, writers or instantiators defined declaratively to be fully initialized and registered before the server starts accepting connections. Keep this in mind when doing programmatic configuration of the items above as the server might start before your components and thus not be seen by the clients connecting right away.

Another configuration addition in SGF 1.1 is the dedicated support for configuring ClientCache - similar to a cache (in both usage and definition) - through the org.springframework.data.gemfire.client package and in particular ClientCacheFactoryBean.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:gfe="http://www.springframework.org/schema/gemfire"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/gemfire http://www.springframework.org/schema/gemfire/spring-gemfire.xsd">
        
    <gfe:client-cache />
     
</beans>

client-cache supports much of the same options as the cache element. However as oppose to a vanilla cache, a client cache connects to a server through a pool (by default a pool is created to connect to a server on localhost and 40404 - the default pool is used by all client cache regions (unless configured to use a different pool)).

Pools can be defined through the pool; in case of client caches and regions pools can be used to customize the connectivity to the server for individual entities or for the entire cache. For example, to custommize the default pool used by client-cache, one needs to define a pool and wire it to cache definition:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:gfe="http://www.springframework.org/schema/gemfire"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/gemfire http://www.springframework.org/schema/gemfire/spring-gemfire.xsd">
        
	<gfe:client-cache id="simple" pool-name="my-pool"/>

	<gfe:pool id="my-pool" subscription-enabled="true">
	    <gfe:locator host="someHost" port="43210"/>
	</gfe:pool>
	 
</beans>

For consuming but not creating Regions (for example in case, the regions are already configured through GemFire native configuration, the cache.xml), one can use the lookup-region element. Simply declare the target region name the name attribute; for example to declare a bean definition, named region-bean for an existing region named orders one can use the following definition:

<gfe:lookup-region id="region-bean" name="orders"/>

If the name is not specified, the bean name will be used automatically. The example above becomes:

<!-- lookup for a region called 'orders' -->
<gfe:lookup-region id="orders"/>

	Note
	If the region does not exist, an initialization exception will be thrown. For configuring new GemFire regions proceed to the sections below for replicated, partitioned, client or advanced region configuration.

Note that in the previous examples, since no cache name was defined, the default SGF naming convention (gemfire-cache) was used. If that is not an option, one can point to the cache bean through the cache-ref attribute:

<gfe:cache id="cache"/>
		
<gfe:lookup-region id="region-bean" name="orders" cache-ref="cache"/>

The lookup-region provides a simple way of retrieving existing, pre-configured regions without exposing the region semantics or setup infrastructure.

One of the common region types supported by GemFire is replicated region or replica. In short:

What is a replica?

When a region is configured to be a replicated region, every member that hosts that region stores a copy of the contents of the region locally. Any update to a replicated region is distributed to all copies of the region. [...] When a replica is created, it goes through an initialization stage in which it discovers other replicas and automatically copies all the entries. While one replica is initializing you can still continue to use the other replicas.

SGF offers a dedicated element for creating replicas in the form of replicated-region element. A minimal declaration looks as follows (again, the example will not setup the cache wiring, relying on the SGF namespace naming conventions):

<gfe:replicated-region id="simple-replica" />

Here, a replicated region is created (if one doesn't exist already). The name of the region is the same as the bean name (simple-replica) and the bean assumes the existence of a GemFire cache named gemfire-cache.

When setting a region, it's fairly common to associate various CacheLoaders, CacheListeners and CacheWriters with it. These components can be either referrenced or declared inlined by the region declaration.

	Note
	Following the GemFire recommandations, the namespace allows for each region created multiple listeners but only one cache writer and cache loader. This restriction can be relaxed, for advanced usages by using the beans declaration (see the next section).

Below is an example, showing both styles:

<gfe:replicated-region id="mixed">
    <gfe:cache-listener>
    	<!-- nested cache listener reference -->
        <ref bean="c-listener"/>
        <!-- nested cache listener declaration -->
        <bean class="some.pkg.SimpleCacheListener"/>
    </gfe:cache-listener>
    <!-- loader reference -->
    <gfe:cache-loader ref="c-loader"/>
    <!-- writer reference -->
    <gfe:cache-writer ref="c-writer"/>
</gfe:replicated-region>

	Warning
	Using ref and a nested declaration on cache-listener, cache-loader or cache-writer is illegal. The two options are mutually exclusive and using them at the same time, on the same element will throw an exception.

Another region type supported out of the box by the SGF namespace, is the partitioned region. To quote again the GemFire docs:

What is a partition?

A partitioned region is a region where data is divided between peer servers hosting the region so that each peer stores a subset of the data. When using a partitioned region, applications are presented with a logical view of the region that looks like a single map containing all of the data in the region. Reads or writes to this map are transparently routed to the peer that hosts the entry that is the target of the operation. [...] GemFire divides the domain of hashcodes into buckets. Each bucket is assigned to a specific peer, but may be relocated at any time to another peer in order to improve the utilization of resources across the cluster.

A partition can be created by SGF through the partitioned-region element. Its configuration options are similar to that of the replicated-region plus the partion specific features such as the number of redundant copies, total maximum memory, number of buckets, partition resolver and so on. Below is a quick example on setting up a partition region with 2 redundant copies:

<!-- bean definition named 'distributed-partition' backed by a region named 'redundant' with 2 copies 
and a nested resolver declaration  -->
<gfe:partitioned-region id="distributed-partition" copies="2" total-buckets="4" name="redundant">
    <gfe:partition-resolver>
        <bean class="some.pkg.SimplePartitionResolver"/>
    </gfe:partition-resolver>
</gfe:partitioned-region>

GemFire supports various deployment topologies for managing and distributing data. The topic is outside the scope of this documentation however to quickly recap, they can be categoried in short in: peer-to-peer (p2p), client-server (or super-peer cache network) and wide area cache network (or WAN). In the last two scenarios, it is common to declare client regions which connect to a backing cache server (or super peer). SGF offers dedicated support for such configuration through Section 2.2.2, “Configuring a GemFire ClientCache”, client-region and pool elements. As the name imply, the former defines a client region while the latter connection pools to be used/shared by the various client regions.

Below is a usual configuration for a client region:

<!-- client region using the default client-cache pool -->
<gfe:client-region id="simple">
    <gfe:cache-listener ref="c-listener"/>
</gfe:client-region>
		
		
<!-- region using its own dedicated pool -->
<gfe:client-region id="complex" pool-name="gemfire-pool">
    <gfe:cache-listener ref="c-listener"/>
</gfe:client-region>
	
<bean id="c-listener" class="some.pkg.SimpleCacheListener"/>

<!-- pool declaration -->	
<gfe:pool id="gemfire-pool" subscription-enabled="true">
    <gfe:locator host="someHost" port="40403"/>
</gfe:pool>

Just as the other region types, client-region allows defining CacheListeners. It also relies on the same naming conventions in case the region name or the cache are not set explicitely. However, it also requires a connection pool to be specified for connecting to the server. Each client can have its own pool or they can share the same one.

For a full list of options to set on the client and especially on the pool, please refer to the SGF schema (Appendix A, Spring GemFire Integration Schema) and the GemFire documentation.

<gfe:client-region id="complex" pool-name="gemfire-pool">
    <gfe:key-interest durable="true" result-policy="KEYS">
        <bean id="key" class="java.lang.String">
             <constructor-arg value="someKey" /> 
        </bean>
    </gfe:key-interest>
    <gfe:regex-interest pattern=".*" receive-values="false"/>
</gfe:client-region>

GemFire can use disk as a secondary storage for persisting regions or/and overflow (known as data pagination or eviction to disk). SGF allows such options to be configured directly from Spring through disk-store element available on both replicated-region and partitioned-region as well as client-region. A disk store defines how that particular region can use the disk and how much space it has available. Multiple directories can be defined in a disk store such as in our example below:

<gfe:partitioned-region id="partition-data">
    <gfe:disk-store queue-size="50" auto-compact="true" max-oplog-size="10" synchronous-write="false" time-interval="9999">
        <gfe:disk-dir location="/mainbackup/partition" max-size="999"/>
        <gfe:disk-dir location="/backup2/partition" max-size="999"/>
    </gfe:disk-store> 
</gfe:replicated-region>

In general, for maximum efficiency, it is recommended that each region that accesses the disk uses a disk store configuration.

For the full set of options and their meaning please refer to the Appendix A, Spring GemFire Integration Schema and GemFire documentation.

Both partitioned and replicated regions can be made persistent. That is:

	What is region persistence?
	GemFire ensures that all the data you put into a region that is configured for persistence will be written to disk in a way that it can be recovered the next time you create the region. This allows data to be recovered after a machine or process failure or after an orderly shutdown and restart of GemFire.

With SGF, to enable persistence, simply set to true the persistent attribute on replicated-region, partitioned-region or client-region:

<gfe:partitioned-region id="persitent-partition" persistent="true"/>

	Important
	Persistence for partitioned regions is supported from GemFire 6.5 onwards - configuring this option on a previous release will trigger an initialization exception.

When persisting regions, it is recommended to configure the storage through the disk-store element for maximum efficiency.

Based on various constraints, each region can have an eviction policy in place for evicting data from memory. Currently, in GemFire eviction applies on the least recently used entry (also known as LRU). Evicted entries are either destroyed or paged to disk (also known as overflow).

SGF supports all eviction policies (entry count, memory and heap usage) for both partitioned-region and replicated-region as well as client-region, through the nested eviction element. For example, to configure a partition to overflow to disk if its size is more then 512 MB, one could use the following configuration:

<gfe:partitioned-region id="overflow-partition">
     <gfe:eviction type="MEMORY_SIZE" threshold="512" action="OVERFLOW_TO_DISK"/>
</gfe:partitioned-region>

	Important
	Replicas cannot use a local destroy eviction since that would invalidate them. See the GemFire docs for more information.

When configuring regions for oveflow, it is recommended to configure the storage through the disk-store element for maximum efficiency.

For a detailed description of eviction policies, see the GemFire documentation (such as this page).

SGF namespaces allow short and easy configuration of the major GemFire regions and associated entities. However, there might be corner cases where the namespaces are not enough, where a certain combination or set of attributes needs to be used. For such situations, using directly the SGF FactoryBeans is a possible alternative as it gives access to the full set of options at the expense of conciseness.

As a warm up, below are some common configurations, declared through raw beans definitions.

A basic configuration looks as follows:

<bean id="basic" class="org.springframework.data.gemfire.RegionFactoryBean">
  <property name="cache">
      <bean class="org.springframework.data.gemfire.CacheFactoryBean"/>
  </property>
  <property name="name" value="basic"/>
</bean>

Notice how the GemFire cache definition has been nested into the declaring region definition. Let's add more regions and make the cache a top level bean.

Since the region bean definition name is usually the same with that of the cache, the name property can be omitted (the bean name will be used automatically). Additionally by using the name the p namespace, the configuration can be simplified even more:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:p="http://www.springframework.org/schema/p"
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
  
    <!-- shared cache across regions -->
    <bean id="cache" class="org.springframework.data.gemfire.CacheFactoryBean"/>

    <!-- region named 'basic' -->
    <bean id="basic" class="org.springframework.data.gemfire.RegionFactoryBean" p:cache-ref="cache"/>

    <!-- region with a name different then the bean definition -->
    <bean id="root-region" class="org.springframework.data.gemfire.RegionFactoryBean" p:cache-ref="cache" p:name="default-region"/>
</beans>

It is worth pointing out, that for the vast majority of cases configuring the cache loader, listener and writer through the Spring container is preferred since the same instances can be reused across multiple regions and additionally, the instances themselves can benefit from the container's rich feature set:

<bean id="cacheLogger" class="org.some.pkg.CacheLogger"/>
<bean id="customized-region" class="org.springframework.data.gemfire.RegionFactoryBean" p:cache-ref="cache">
  <property name="cacheListeners">
    <array>
      <ref name="cacheLogger"/>
    <bean class="org.some.other.pkg.SysoutLogger"/>
    </array>
  </property>
  <property name="cacheLoader"><bean class="org.some.pkg.CacheLoad"/></property>
  <property name="cacheWriter"><bean class="org.some.pkg.CacheWrite"/></property>
</bean>

<bean id="local-region" class="org.springframework.data.gemfire.RegionFactoryBean" p:cache-ref="cache">
  <property name="cacheListeners" ref="cacheLogger"/>	
</bean>

For scenarios where a CacheServer is used and clients need to be configured and the namespace is not an option, SGF offers a dedicated configuration class named: ClientRegionFactoryBean. This allows client interests to be registered in both key and regex form through Interest and RegexInterest classes in the org.springframework.data.gemfire.client package:

<bean id="interested-client" class="org.springframework.data.gemfire.client.ClientRegionFactoryBean" p:cache-ref="cache" p:name="client-region">
  <property name="interests">
    <array>
      <!-- key-based interest -->
      <bean class="org.springframework.data.gemfire.client.Interest" p:key="Vlaicu" p:policy="NONE"/>
      <!-- regex-based interest -->
      <bean class="org.springframework.data.gemfire.client.RegexInterest" p:key=".*" p:policy="KEYS" p:durable="true"/>
    </array>
  </property>
</bean>

Users that need fine control over a region, can configure it in Spring by using the attributes property. To ease declarative configuration in Spring, SGF provides two FactoryBeans for creating RegionAttributes and PartitionAttributes, namely RegionAttributesFactory and PartitionAttributesFactory. See below an example of configuring a partitioned region through Spring XML:

<bean id="partitioned-region" class="org.springframework.data.gemfire.RegionFactoryBean" p:cache-ref="cache">
  <property name="attributes">
    <bean class="org.springframework.data.gemfire.RegionAttributesFactory" p:initial-capacity="1024">
      <property name="partitionAttributes">
        <bean class="org.springframework.data.gemfire.PartitionAttributesFactoryBean" p:redundant-copies="2" p:local-max-memory="512"/>
      </property>
    </bean>
  </property>
</bean>

By using the attribute factories above, one can reduce the size of the cache.xml or even eliminate it all together.