diff --git a/docs/src/docbkx/reference/bootstrap.xml b/docs/src/docbkx/reference/bootstrap.xml
index 20f2c254..38151506 100644
--- a/docs/src/docbkx/reference/bootstrap.xml
+++ b/docs/src/docbkx/reference/bootstrap.xml
@@ -231,7 +231,7 @@
- Configuring a GemFire replicated region
+ Replicated Region
One of the common region types supported by GemFire is replicated region or replica. In short:
@@ -333,7 +333,7 @@
- Configuring a GemFire partition(ed) region
+ Partition(ed) Region
Another region type supported out of the box by the SGF namespace, is the partitioned region. To quote again the GemFire docs:
@@ -513,38 +513,79 @@ redundancy. Each copy provides extra backup at the expense of extra storages.
]]>
+ 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).
-
- In a similar manner to the
- cache element, SGF
-
- RegionFactoryBean allows existing
- Regions 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
- CacheLoaders,
- CacheListeners and
- CacheWriters and if needed, the
- RegionAttributes for full
- customization.
+
+ Client 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 the
+ 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:
+
+
+
+
+
+
+
- Let us start with a simple region declaration, named
- basic using a nested cache declaration:
+
+
+
+]]>
- <bean id="basic" class="org.springframework.data.gemfire.RegionFactoryBean">
+ 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 () and the GemFire documentation.
+
+
+ Client Interests
+
+ To minimize network traffic, each client can define its own 'interest', pointing out to GemFire, the data it actually needs. In SGF, interests can be defined for each client, both
+ key-based and regular-expression-based types being supported; for example:
+
+
+
+
+
+
+]]>
+
+
+
+
+ Advanced Region Configuration
+
+ 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>
- Since the region bean definition name is usually the same with that
+ 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
-
- Configuring a <emphasis>client</emphasis>
- <interfacename>Region</interfacename>
-
For scenarios where a CacheServer is used and
- clients need to be configured, SGF offers a
+ 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 package:
+ 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">
@@ -612,10 +649,6 @@ redundancy. Each copy provides extra backup at the expense of extra storages.
-
-
-
- Advanced configuration through a <interfacename>Region</interfacename>'s <emphasis>attributes</emphasis>
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,
@@ -636,4 +669,10 @@ redundancy. Each copy provides extra backup at the expense of extra storages.By using the attribute factories above, one can reduce the size of the cache.xml or even eliminate it all together.
+
+
+ Advantages of using Spring over GemFire <literal>cache.xml</literal>
+
+
+
\ No newline at end of file