One of the first tasks when using GemFire and Spring is to configure the data grid through the IoC container. While this is possible out of the box, the configuration tends to be verbose and only address basic cases. To address this problem, the Spring GemFire project provides several classes that enable the configuration of distributed caches or regions to support a variety of scenarios with minimal effort.
In order to use the GemFire Fabric, one needs to either create a new
Cache
or connect to an existing one. As in
the current version of GemFire, there can be only one opened cache per VM
(or classloader to be technically correct). In most cases the cache is
created once and then all other consumers connect to it.
In its simplest form, a cache can be defined in one line:
<bean id="default-cache" class="org.springframework.data.gemfire.CacheFactoryBean"/>
Here, the default-cache will try to connect to an existing cache and, in case one does not exist, create it. Since no additional properties were specified the created cache uses the default cache configuration.
Especially in environments with opened caches, this basic configuration can go a long way. For scenarios where the cache needs to be configured, the user can pass in a reference the GemFire configuration file:
<bean id="cache-with-xml" class="org.springframework.data.gemfire.CacheFactoryBean"> <property name="cacheXml" value="classpath:cache.xml"/> </bean>
In this example, if the cache needs to be created, it will use the
file named cache.xml
located in the classpath root.
Only if the cache is created will the configuration file be used.
Note | |
---|---|
Note that the configuration makes use of Spring's |
In addition to referencing an external configuration file one can
specify GemFire settings directly through Java
Properties
. This can be quite handy when just a few
settings need to be changed:
<bean id="cache-with-props" class="org.springframework.data.gemfire.CacheFactoryBean"> <property name="properties"> <props> <prop key="bind-address">127.0.0.1</prop> </props> </property> </bean>
So far our examples relied on the primary Spring namespace
(beans
). However one is free to add other namespaces to
simplify or enhance the configuration. Let's do the same thing to the
configuration above by using the util
namespace and
externalize the properties from the configuration which is a best
practice.
<?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:util="http://www.springframework.org/schema/util" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd"> <bean id="cache-with-props" class="org.springframework.data.gemfire.CacheFactoryBean"> <property name="properties"> <util:properties location="classpath:/deployment/env.properties"/> </property> </bean> </beans>
It is worth pointing out again, that the cache settings apply only if the cache needs to be created, there is no opened cache in existence otherwise the existing cache will be used and the configuration will simply be discarded.
Once the Cache
is configured, one
needs to configure one or more Region
s to
interact with the data fabric. In a similar manner to the
CacheFactoryBean
, the
RegionFactoryBean
allows existing
Region
s to retrieved or, in case they don't
exist, created using various settings. One can specify the
Region
name, whether it will be destroyed
on shutdown (thereby acting as a temporary cache), the associated
CacheLoader
s,
CacheListener
s and
CacheWriter
s and if needed, the
RegionAttributes
for full
customization.
Let us start with a simple region declaration, named basic using a nested cache declaration:
<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>
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, SGI 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
package:
<bean id="interested-client" class="org.springframework.data.gemfire.ClientRegionFactoryBean" p:cache-ref="cache" p:name="client-region"> <property name="interests"> <array> <!-- key-based interest --> <bean class="org.springframework.data.gemfire.Interest" p:key="Vlaicu" p:policy="NONE"/> <!-- regex-based interest --> <bean class="org.springframework.data.gemfire.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,
SGI provides two FactoryBean
s 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.PartitionAttributesFactory" 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.