1.4.1.RELEASE
Note | |
---|---|
As of the 1.2.0 release, this project, formerly known as Spring GemFire, has been renamed to Spring Data GemFire to reflect that it is now a component of the Spring Data project. |
Table of Contents
cache.xml
Spring Data GemFire focuses on integrating the Spring Framework's powerful, non-invasive programming model and concepts with Pivotal GemFire, simplifying configuration, development and providing high-level abstractions. This document assumes the reader already has a basic familiarity with the Spring Framework and Pivotal GemFire concepts and APIs.
While every effort has been made to ensure this documentation is comprehensive and there are no errors, some topics might require more explanation and some typos might have crept in. If you do spot any mistakes or even more serious errors and you can spare a few cycles, please do bring the errors to the attention of the Spring Data GemFire team by raising an issue. Thank you.
This reference guide for Spring Data GemFire explains how to use the Spring Framework to configure and develop applications with Pivotal GemFire. It presents the basic concepts, semantics and provides numerous examples to help you get started.
Note | |
---|---|
Spring Data GemFire started as a top-level Spring project called Spring GemFire (SGF) and since then has been moved under the Spring Data umbrella project and renamed accordingly. |
Spring Data GemFire requires JDK 6.0 or above, Spring Framework 3 and Pivotal GemFire 6.6 or above (version 7 or above is recommended).
Note | |
---|---|
As of the 1.2.0 release, this project, formerly known as Spring GemFire, has been renamed to Spring Data GemFire to reflect that it is now a component of the Spring Data project. |
Full support for GemFire configuration via the SDG gfe namespace. Now GemFire components may be configured completely without requiring a native cache.xml file.
WAN Gateway support for GemFire 6.6.x. See Section 5.9, “Configuring WAN Gateways”.
Spring Data Repository support using a dedicated SDG namespace, gfe-data. See Chapter 9, GemFire Repositories
Namespace support for registering GemFire Functions. See Section 5.8, “Configuring GemFire's Function Service”
A top-level <disk-store>
element has been added to the SDG
gfe namespace to allow sharing of persist stores among Regions,
and other components that support persistent backup or overflow.
See Section 5.7, “Configuring a Disk Store”
Caution | |
---|---|
The <*-region> elements no longer allow a nested
<disk-store>
|
GemFire Sub-Regions are supported via nested <*-region>
elements.
A <local-region>
element has been added to configure a Local Region.
Annotation support for GemFire Functions. It is now possible to declare and register Functions written as POJOs using annotations. In addition, Function executions are defined as annotated interfaces, similar to the way Spring Data Repositories work. See Chapter 10, Annotation Support for Function Execution.
Added a <datasource>
element to the SDG gfe-data namespace to
simplify establishing a basic client connection
to a GemFire data grid.
Added a <json-region-autoproxy>
element to the SDG gfe-data
namespace to support JSON features introduced
in GemFire 7.0, enabling Spring AOP to perform the necessary conversions automatically
on Region operations.
Upgraded to GemFire 7.0.1 and added namespace support for new AsyncEventQueue attributes.
Added support for setting subscription interest policy on Regions.
Support for void returns on Function executions. See Chapter 10, Annotation Support for Function Execution for complete details.
Support for persisting Local Regions. See Section 5.5.8, “Local Region” and the section called “Common Region Attributes”.
Support for entry time-to-live and entry idle-time on a GemFire Client Cache. See Section 5.3.3, “Configuring a GemFire Client Cache”
Support for multiple Spring Data GemFire web-based applications using a single GemFire cluster, operating concurrently inside tc Server.
Support for concurrency-checks-enabled on all GemFire Cache Region definitions using the SDG gfe namespace. See the section called “Common Region Attributes”.
Support for Cache Loaders and Cache Writers on Client, Local Regions. See the section called “Cache Loaders and Cache Writers”.
Support for registering CacheListeners, AsyncEventQueues and Gateway Senders on GemFire Cache Sub-Regions.
Support for PDX persistent keys in GemFire Regions.
Support for correct Partition Region bean creation in a Spring context when collocation is specified with the colocated-with attribute.
Full support for GemFire Cache Sub-Regions using proper, nested <*-region>
element syntax in the SDG gfe namespace.
Upgraded Spring Data GemFire to Spring Framework 3.2.8.
Upgraded Spring Data GemFire to Spring Data Commons 1.7.1.
Upgrades Spring Data GemFire to GemFire 7.0.2.
Upgrades Spring Data GemFire to Spring Data Commons 1.8.0.
Integrates Spring Data GemFire with Spring Boot, which includes both a spring-boot-starter-data-gemfire POM along with a Spring Boot Sample application demonstrating GemFire Cache Transactions configured with SDG bootstrapped with Spring Boot.
Support for bootstrapping a Spring Context in a GemFire Server when started from Gfsh. See Chapter 11, Bootstrapping a Spring ApplicationContext in GemFire.
Support for persisting application domain object/entities to multiple GemFire Cache Regions. See Section 8.1, “Entity Mapping” for more details.
Support for persisting application domain object/entities to GemFire Cache Sub-Regions, avoiding collisions when Sub-Regions are uniquely identifiable, but identically named. See Section 8.1, “Entity Mapping” for more details.
Adds strict XSD type rules to, and full support for, Data Policies and Region Shortcuts on all GemFire Cache Region types.
Changed the default behavior of SDG <*-region>
elements from lookup
to always create a new Region along with an option to restore old behavior using the
ignore-if-exists attribute.
See Common Region Attributes
and Section 5.5.3, “A Word of Caution on Regions, Subregions and Lookups”
for more details.
Enables Spring Data GemFire to be fully built and ran on JDK 7 and JDK 8 (Note, however, GemFire has not yet been fully tested and supported on JDK 8; See GemFire User Guide for additional details.
The following chapters explain the core functionality offered by Spring Data GemFire.
Chapter 5, Bootstrapping GemFire through the Spring Container describes the configuration support provided for bootstrapping, configuring, initializing and accessing GemFire Caches, Cache Servers, Regions, and related Distributed System components.
Chapter 6, Working with the GemFire APIs explains the integration between the GemFire APIs and the various data access features available in Spring, such as transaction management and exception translation.
Chapter 7, Working with GemFire Serialization describes the enhancements for GemFire (de)serialization and management of associated objects.
Chapter 8, POJO mapping describes persistence mapping for POJOs stored in GemFire using Spring Data.
Chapter 9, GemFire Repositories describes how to create and use GemFire Repositories using Spring Data.
Chapter 10, Annotation Support for Function Execution describes how to create and use GemFire Functions using annotations.
Chapter 11, Bootstrapping a Spring ApplicationContext in GemFire describes how to bootstrap a Spring ApplicationContext running in a GemFire Server using Gfsh.
Chapter 12, Sample Applications describes the samples provided with the distribution to illustrate the various features available in Spring Data GemFire.
Spring Data GemFire provides full configuration and initialization of the GemFire data grid through Spring's IoC container and provides several classes that simplify the configuration of GemFire components including Caches, Regions, WAN Gateways, Persistence Backup, and other Distributed System components to support a variety of scenarios with minimal effort.
Note | |
---|---|
This section assumes basic familiarity with GemFire. For more information see the product documentation. |
As of release 1.2.0, Spring Data GemFire's XML namespace
supports full configuration of the data grid. In fact, the Spring Data
GemFire namespace is considered the preferred way to configure GemFire.
GemFire will continue to support native
for legacy reasons, but you can now do everything in Spring
XML and take advantage of the many wonderful things Spring has to offer
such as modular XML configuration, property placeholders, SpEL, and
environment profiles. Behind the namespace, Spring Data GemFire makes
extensive use of Spring's cache.xml
FactoryBean
pattern to simplify the creation and initialization of GemFire
components.
For example, GemFire provides several callback interfaces
such as
CacheListener,
andCacheWriter,
to allow developers to add custom event handlers. Using
the Spring IoC container, these may configured as normal Spring beans and
injected into GemFire components. This is a significant improvement over
native CacheLoader
cache.xml
which provides relatively limited configuration options and requires
callbacks to implement GemFire's
interface (see Section 6.6, “Wiring Declarable
Declarable
components” to see how you can still use
Declarables
within Spring's DI container).
In addition, IDEs such as the Spring Tool Suite (STS) provide excellent support for Spring XML namespaces, such as code completion, pop-up annotations, and real time validation, making them easy to use.
To simplify configuration, Spring Data GemFire provides a dedicated XML namespace for configuring core GemFire components. It is also possible to configure the beans directly through Spring's standard <bean> definition. However, as of Spring Data GemFire 1.2.0, all bean properties are exposed via the namespace so there is little benefit to using raw bean definitions. For more information about XML Schema-based configuration in Spring, see this appendix in the Spring Framework reference documentation.
Note | |
---|---|
Spring Data Repository support uses a separate XML namespace. See Chapter 9, GemFire Repositories for more information on how to configure GemFire Repositories. |
To use the Spring Data GemFire namespace, simply declare it in your Spring XML configuration meta-data:
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlxsi="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"> <bean id ... > <gfe:cache ...> </beans>
Spring GemFire namespace prefix. Any name will do but through
out the reference documentation, | |
The namespace URI. | |
The namespace URI location. Note that even though the location points to an external address (which exists and is valid), Spring will resolve the schema locally as it is included in the Spring Data GemFire library. | |
Declaration example for the GemFire namespace. Notice the prefix usage. |
Once declared, the namespace elements can be declared simply by appending the aforementioned prefix.
In order to use GemFire, one needs to either create a new
Cache
or connect to an existing one. In the
current version of GemFire, there can be only one opened cache per VM (or
per classloader to be technically correct). In most cases the cache is
created once.
Note | |
---|---|
This section describes the creation and configuration of a full cache member, appropriate for peer to peer cache topologies and cache servers. A full cache is also commonly used for standalone applications, integration tests and proofs of concept. In a typical production system, most application processes will act as cache clients and will create a ClientCache instance instead. This is described in the sections Section 5.3.3, “Configuring a GemFire Client Cache” and Section 5.5.11, “Client Region” |
A cache with default configuration can be created with a very simple declaration:
<gfe:cache/>
A Spring application context containing this definition will, upon
initialization, will register a CacheFactoryBean
to
create a Spring bean named gemfireCache
referencing a
GemFire Cache
instance. This will be either
an existing cache, or if one does not exist, a newly created one. Since no
additional properties were specified, a newly created cache will apply the
default cache configuration.
All Spring Data GemFire components which depend on the Cache respect
this naming convention so that there is no need to explicitly declare the
Cache dependency. If you prefer, you can make the dependence explicit via
the cache-ref
attribute provided by various namespace
elements. Also you can easily override the Cache's bean name:
<gfe:cache id="my-cache"/>
Starting with Spring Data GemFire 1.2.0, The GemFire Cache may be
fully configured using Spring. However, GemFire's native XML configuration
file (e.g., cache.xml) is also supported. For scenarios in which the GemFire
cache needs to be configured natively, simply provide a reference the
GemFire configuration file using the cache-xml-location
attribute:
<gfe:cache id="cache-with-xml" cache-xml-location="classpath:cache.xml"/>
In this example, if the cache needs to be created, it will use the
file named cache.xml
located in the classpath
root.
Note | |
---|---|
Note that the configuration makes use of Spring's
|
In addition to referencing an external configuration file one can
specify GemFire properties
using any of Spring's common properties support features. For example, one
can use the properties
element defined in the
util
namespace to define properties directly or load
properties from properties files. The latter is recommended for
externalizing environment specific settings outside the application
configuration:
<?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: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/gemfire http://www.springframework.org/schema/gemfire/spring-gemfire.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd"> <gfe:cache properties-ref="props"/> <util:properties id="props" location="file:/vfabric/gemfire/gemfire.properties"/> </beans>
Note | |
---|---|
The cache settings apply only if a new cache needs to be created. If an open cache already exists in the JVM, these settings will be ignored. |
For advanced cache configuration, the cache
element provides a number of configuration options exposed as attributes
or child elements
<gfe:cache copy-on-read="true" critical-heap-percentage="70" eviction-heap-percentage="60" lock-lease="120" lock-timeout="60" pdx-serializer="myPdxSerializer" pdx-disk-store="diskStore" pdx-ignore-unread-fields="true" pdx-persistent="true" pdx-read-serialized="false" message-sync-interval="1" search-timeout="300" close="false" lazy-init="true" > <gfe:transaction-listener ref="myTransactionListener"/> <gfe:transaction-writer> <bean class="org.springframework.data.gemfire.example.TransactionListener"/> </gfe:transaction-writer> <gfe:dynamic-region-factory/> <gfe:jndi-binding jndi-name="myDataSource" type="ManagedDataSource"/> </gfe:cache>
Various cache options are supported by attributes. For further information regarding anything shown in this example, please consult the GemFire product documentation The The | |
An example of a
| |
An example of a | |
Enable GemFire's DynamicRegionFactory | |
Declares a JNDI binding to enlist an external datasource in a GemFire transaction |
Note | |
---|---|
The use-bean-factory-locator attribute
(not shown) deserves a mention. The factory bean responsible for creating
the cache uses an internal Spring type called a BeanFactoryLocator to enable user classes
declared in GemFire's native cache.xml to be
registered as Spring beans. The BeanFactoryLocator implementation also permits
only one bean definition for a cache with a given id. In certain
situations, such as running JUnit integration tests from within Eclipse,
it is necessary to disable the BeanFactoryLocator by setting this value to
false to prevent an exception. This exception
may also arise during JUnit tests running from a build script. In this
case the test runner should be configured to fork a new JVM for each test
(in maven, set <forkmode>always</forkmode> ) . Generally
there is no harm in setting this value to false. |
The example above includes a number of attributes related to
GemGire's enhanced serialization framework, PDX. While a complete
discussion of PDX is beyond the scope of this reference guide, it is
important to note that PDX is enabled by registering a PDX serializer
which is done via the pdx-serializer
attribute.
GemFire provides an implementation class
com.gemstone.gemfire.pdx.ReflectionBasedAutoSerializer
,
however it is common for developers to provide their own implementation.
The value of the attribute is simply a reference to a Spring bean that
implements the required interface. More information on serialization
support can be found in Chapter 7, Working with GemFire Serialization
In Spring Data GemFire 1.1 dedicated support for configuring a CacheServer was added, 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:context="http://www.springframework.org/schema/context" 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"> <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:cache-server.properties"/> </beans>
The configuration above illustrates the
cache-server
element and the many options
available.
Note | |
---|---|
Rather than hard-coding the port, this configuration uses Spring's
|
Note | |
---|---|
To avoid initialization problems, the
|
Another configuration addition in Spring Data GemFire 1.1 is the
dedicated support for configuring ClientCache.
This is similar to a cache in both
usage and definition and supported by
org.springframework.data.gemfire.clientClientCacheFactoryBean
.
<beans> <gfe:client-cache /> </beans>
client-cache
supports much of the same options as
the cache element. However as opposed to a
full cache, a client cache connects to a remote cache
server through a pool. By default a pool is created to connect to a server
on localhost
port 40404
. The the
default pool is used by all client regions unless the region is configured
to use a different pool.
Pools can be defined through the pool
element;
The client side pool
can be used to configure
connectivity to the server for individual entities or for the entire
cache. For example, to customize the default pool used by
client-cache
, one needs to define a pool and wire it to
cache definition:
<beans> <gfe:client-cache id="simple" pool-name="my-pool"/> <gfe:pool id="my-pool" subscription-enabled="true"> <gfe:locator host="${locatorHost}" port="${locatorPort}"/> </gfe:pool> </beans>
The <client-cache> tag also includes a ready-for-events
attribute. If set to true
, the client cache initialization will include
ClientCache.readyForEvents().
Client side configuration is covered in more detail in Section 5.5.11, “Client Region”.
In addition to the core gfe
namespace, Spring Data
GemFire provides a gfe-data
namespace intended primarily
to simplify the development of GemFire client applications. This namespace
currently supports for GemFire repositories and function execution and a
<datasource>
tag that offers a convenient way to connect to
the data grid.
For many applications, A basic connection to a GemFire grid, using
default values is sufficient. Spring Data GemFire's <datasource>
tag
provides a simple way to access data. The data source creates a client
cache and connection pool. In addition, it will query the member servers
for all existing root regions and create a proxy (empty) client region for
each one.
<gfe-data:datasource> <locator host="somehost" port="1234"/> </gfe-data:datasource>
The datasource tag is synactically similar to <gfe:pool>
.
It may be configured with one or more locator or server tags to connect to
an existing data grid. Additionally, all attributes available to configure
a pool are supported. This configuration will automatically create
ClientRegion beans for each region defined on members connected to the
locator, so they may be seamlessly referenced by Spring Data mapping
annotations, GemfireTemplate, and wired into application
classes.
Of course, you can explicitly configure client regions. For example, if you want to cache data in local memory:
<gfe-data:datasource> <locator host="somehost" port="1234"/> </gfe-data:datasource> <gfe:client-region id="Customer" shortcut="CACHING_PROXY"/>
A region is required to store and retrieve data from the
cache. Region
is an interface extending
java.util.Map
and enables basic data access
using familiar key-value semantics. The
Region
interface is wired into classes that
require it so the actual region type is decoupled from the programming model
. Typically each region is associated with one domain object, similar to a
table in a relational database.
GemFire implements the following types of regions:
Replicated - Data is replicated across all cache members that define the region. This provides very high read performance but writes take longer to perform the replication.
Partioned - Data is partitioned into buckets among cache members that define the region. This provides high read and write performance and is suitable for very large data sets that are too big for a single node.
Local - Data only exists on the local node.
Client - Technically a client region is a local region that acts as a proxy to a replicated or partitioned region hosted on cache servers. It may hold data created or fetched locally. Alternately, it can be empty. Local updates are synchronized to the cache server. Also, a client region may subscribe to events in order to stay synchronized with changes originating from remote processes that access the same region.
For more information about the various region types and their capabilities as well as configuration options, please refer to the GemFire Developer's Guide and community site.
For referencing regions already configured through GemFire native
configuration, e.g. a cache.xml
file, use the
lookup-region
element. Simply declare the target region
name with thename
attribute; for example, to declare a
bean definition named region-bean
for an existing
region named Orders
one can use the following bean
definition:
<gfe:lookup-region id="region-bean" name="Orders"/>
If the name
is not specified, the bean's
id
will be used. 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 appropriate sections below. |
Note, in the previous examples, since no cache name was defined,
the default naming convention (gemfireCache
) was used.
Alternately, one can reference 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.
Spring Data GemFire provides comprehensive support for configuring any type of GemFire Region via the following elements:
Local Region <local-region>
Replicated Region <replicated-region>
Partitioned Region <partitioned-region>
Client Region <client-region>
For a comprehensive description of Region types please consult the GemFire product documentation.
The following table(s) list attributes available for various region types:
Table 5.1. Common Region Attributes
Name | Values | Description |
---|---|---|
cache-ref | GemFire Cache bean name | The name of the bean defining the GemFire Cache (by default 'gemfireCache'). |
close | boolean, default:false (Note: The default was true prior to 1.3.0) | Indicates whether the Region should be closed at shutdown. |
concurrency-checks-enables | boolean, default:true | Determines whether members perform checks to provide consistent handling for concurrent or out-of-order updates to distributed Regions. |
data-policy | See GemFire's Data Policy | The Region's Data Policy. Note, not all Data Policies are supported for every Region type. |
destroy | boolean, default:false | Indicates whether the Region should be destroyed at shutdown. |
disk-store-ref | The name of a configured Disk Store. | A reference to a bean created via the
disk-store element.
|
disk-synchronous | boolean, default:false | Indicates whether Disk Store writes are synchronous. |
enable-gateway | boolean, default:false | Indicates whether the Region will synchronize entries over a WAN Gateway. |
hub-id | The name of the Gateway Hub. | This will automatically set enable-gateway to true. If enable-gateway is explicitly set to false, an exception will be thrown. |
id | Any valid bean name. | Will also be the Region name by default. |
ignore-if-exists | boolean, default:false | Ignores this bean definition configuration if the Region already exists in the GemFire Cache, resulting in a lookup instead. |
ignore-jta | boolean, default:false | Indicates whether the Region participates in JTA transactions. |
index-update-type | synchronous or asynchronous, default:asynchronous | Indicates whether indices will be updated synchronously or asynchronously on entry creation. |
initial-capacity | integer, default:16 | The initial memory allocation for number of Region entries. |
key-constraint | Any valid, fully-qualified Java class name. | The expected key type. |
name | Any valid Region name. | The name of the Region definition. If not specified, it will assume the value of the id attribute (the bean name). |
persistent | boolean, default:false | Indicates whether the Region persists entries to a Disk Store (disk). |
statistics | boolean, default:false | Indicates whether the Region reports statistics. |
value-constraint | Any valid, fully-qualified Java class name. | The expected value type. |
Cache Listeners are registered with a region to handle region
events such as entries being created, updated, destroyed, etc. A Cache
Listener can be any bean that implements the
CacheListener
interface. A region may have multiple listeners, declared
using the cache-listener
element enclosed in a
*-region
element. In the example below, there are two
CacheListener
s declared. The first
references a top-level named Spring bean; the second is an anonymous
inner bean definition.
<gfe:replicated-region id="region-with-listeners"> <gfe:cache-listener> <!-- nested cache listener reference --> <ref bean="c-listener"/> <!-- nested cache listener declaration --> <bean class="some.pkg.AnotherSimpleCacheListener"/> </gfe:cache-listener> <bean id="c-listener" class="some.pkg.SimpleCacheListener"/> </gfe:replicated-region>
The following example uses an alternate form of the
cache-listener
element with a ref
attribute. This allows for more concise configuration for a single cache
listener. Note that the namespace only allows a single
cache-listener
element so either the style above or
below must be used.
Caution | |
---|---|
Using |
<beans> <gfe:replicated-region id="region-with-one listener"> <gfe:cache-listener ref="c-listener"/> </gfe:replicated-region> <bean id="c-listener" class="some.pkg.SimpleCacheListener"/> </beans>
Bean Reference Conventions | |
---|---|
The |
Similar to cache-listener
, the namespace
provides cache-loader
and
cache-writer
elements to register these respective
components for a region. A CacheLoader
is
invoked on a cache miss to allow an entry to be loaded from an external
data source, a database for example. A
CacheWriter
is invoked after an entry is
created or updated, intended for synchronizing to an external data
source. The difference is GemFire only supports at most a single
instance of each for each region. However, either declaration style may
be used. See
CacheLoader
and
CacheWriter
for more details.
In Release 1.2.0, Spring Data GemFire added support for subregions, allowing regions to be arranged in a hierarchical relationship. For example, GemFire allows for a /Customer/Address region and a different /Employee/Address region. Additionally, a subregion may have it's own subregions and its own configuration. A subregion does not inherit attributes from the parent region. Regions types may be mixed and matched subject to GemFire constraints. A subregion is naturally declared as a child element of a region. The subregion's name attribute is the simple name. The above example might be configured as:
<beans> <gfe:replicated-region name="Customer"> <gfe:replicated-region name="Address"/> </gfe:replicated-region> <gfe:replicated-region name="Employee"> <gfe:replicated-region name="Address"/> </gfe:replicated-region> </beans>
Note that the
attribute is not permitted for a subregion. The subregions
will be created with bean names /Customer/Address
and /Employee/Address, respectively. So they may be
injected using the full path name into other beans that use them, such
as id
GemfireTemplate
. The full path should also be
used in OQL query strings.
Prior to Spring Data GemFire 1.4, one of the underlying properties of the high-level
replicated-region
, partitioned-region
, local-region
and client-region
elements in Spring Data GemFire's XML namespace, which correspond to
GemFire's Region types based on Data Policy, is that these elements perform a lookup first before attempting
to create the region. This is done in case the region already exists, which might be the case if the region
was defined in GemFire's native configuration, e.g. cache.xml
, thereby avoiding any errors.
This was by design, though subject to change.
Caution | |
---|---|
The Spring team highly recommends that the |
Important | |
---|---|
Recommended Practice - Only use the |
However, because the high-level region elements perform a lookup first, this can cause problems for dependency injected region resources to application code, like DAOs or Repositories.
Take for instance the following native GemFire configuration file
(e.g. cachel.xml
)...
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE cache PUBLIC "-//GemStone Systems, Inc.//GemFire Declarative Caching 7.0//EN" "http://www.gemstone.com/dtd/cache7_0.dtd"> <cache> <region name="Customers" refid="REPLICATE"> <region name="Accounts" refid="REPLICATE"> <region name="Orders" refid="REPLICATE"> <region name="Items" refid="REPLICATE"/> </region> </region> </region> </cache>
Also, consider that you might have defined a DAO as follows...
public class CustomerAccountDao extends GemDaoSupport { @Resource(name = "Customers/Accounts") private Region customersAccounts; ... }
Here, we are injecting a reference to the Customers/Accounts
GemFire Region in
our DAO. As such, it is not uncommon for a developer to define beans for all or some of these regions in
Spring XML configuration meta-data as follows...
<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:gfe="http://www.springframework.org/schema/gemfire" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 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:cache cache-xml-location="classpath:cache.xml"/> <gfe:lookup-region name="Customers/Accounts"/> <gfe:lookup-region name="Customers/Accounts/Orders"/> </beans>
Here the Customers/Accounts
and Customers/Accounts/Orders
GemFire Regions are referenced as beans in the Spring context as "Customers/Accounts"
and "Customers/Accounts/Orders", respectively. The nice thing about using the
lookup-region
element and the corresponding syntax above is that it allows
a developer to reference a subregion directly without unnecessarily defining a bean for the
parent region (e.g. Customers
).
However, if now the developer changes his/her configuration meta-data syntax to using the nested format, like so...
<gfe:lookup-region name="Customers"> <gfe:lookup-region name="Accounts"> <gfe:lookup-region name="Orders"/> </gfe:lookup-region> </gfe:lookup-region>
Or, perhaps the developer erroneously chooses to use the high-level
replicated-region
element, which will do a lookup first, as in...
<gfe:replicated-region name="Customers" persistent="true"> <gfe:replicated-region name="Accounts" persistent="true"> <gfe:replicated-region name="Orders" persistent="true"/> </gfe:replicated-region> </gfe:replicated-region>
Then the region beans defined in the Spring context will consist of the following:
{ "Customers", "/Customers/Accounts", "/Customers/Accounts/Orders" }.
This means the dependency injected reference (i.e. @Resource(name = "Customers/Accounts"))
is now broken since no bean with name "Customers/Accounts" is defined.
GemFire is flexible in referencing both parent regions and subregions. The parent can be referenced as "/Customers" or "Customers" and the child as "/Customers/Accounts" or just "Customers/Accounts". However, Spring Data GemFire is very specific when it comes to naming beans after regions, typically always using the forward slash (/) to represents subregions (e.g. "/Customers/Accounts").
Therefore, it is recommended that users use either the nested lookup-region
syntax as illustrated above, or define direct references with a leading forward slash (/) like so...
<gfe:lookup-region name="/Customers/Accounts"/> <gfe:lookup-region name="/Customers/Accounts/Orders"/>
The example above where the nested replicated-region
elements were used to
reference the subregions serves to illustrate the problem stated earlier. Are the Customers, Accounts
and Orders Regions/Subregions persistent or not? Not, since the regions were defined in native GemFire
configuration (i.e. cache.xml
) and will exist by the time the cache is initialized,
or once the <gfe:cache>
bean is created. Since the high-level region
XML namespace abstractions, like replicated-region
, perform the lookup first, it
uses the regions as defined in the cache.xml
configuration file.
Regions can be made persistent. 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.
To enable persistence with Spring Data GemFire, simply set the
persistent
attribute to true:
<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. |
Persistence may also be configured using the
data-policy
attribute, set to one of GemFire's
data policy settings. For instance...
<gfe:partitioned-region id="persitent-partition" data-policy="PERSISTENT_PARTITION"/>
The data policy must match the region type and must also agree with
the persistent
attribute if explicitly set. An
initialization exception will be thrown if, for instance, the
persistent
attribute is set to false, yet a persistent
data policy was specified.
When persisting regions, it is recommended to configure the storage
through the disk-store
element for maximum efficiency.
The diskstore is referenced using the disk-store-ref attribute.
Additionally, the region may perform disk writes synchronously or
asynchronously:
<gfe:partitioned-region id="persitent-partition" persistent="true" disk-store-ref="myDiskStore" disk-synchronous="true"/>
This is discussed further in Section 5.7, “Configuring a Disk Store”
GemFire allows configuration of subscriptions to control peer
to peer event handling. Spring Data GemFire provides a
<gfe:subscription/>
to set the interest policy on
replicated and partitioned regions to either ALL
or
CACHE_CONTENT
.
<gfe:partitioned-region id="subscription-partition"> <gfe:subscription type="CACHE_CONTENT"/> </gfe:partitioned-region>
Based on various constraints, each region can have an eviction policy in place for evicting data from memory. Currently, in GemFire, eviction applies to the least recently used entry (also known as LRU). Evicted entries are either destroyed or paged to disk (also known as overflow).
Spring Data GemFire 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 |
When configuring regions for overflow, 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).
Time to live (TTL) - The amount of time, in seconds, the object may remain in the cache after the last creation or update. For entries, the counter is set to zero for create and put operations. Region counters are reset when the region is created and when an entry has its counter reset.
Idle timeout - The amount of time, in seconds, the object may remain in the cache after the last access. The idle timeout counter for an object is reset any time its TTL counter is reset. In addition, an entry’s idle timeout counter is reset any time the entry is accessed through a get operation or a netSearch . The idle timeout counter for a region is reset whenever the idle timeout is reset for one of its entries.
Each of these may be applied to the region itself or
entries in the region. Spring Data GemFire provides
<region-ttl>
,
<region-tti>
, <entry-ttl>
and <entry-tti>
region child elements to specify
timeout values and expiration actions.
Spring Data GemFire offers a dedicated
local-region
element for creating local regions. Local
regions, as the name implies, are standalone meaning they do not share
data with any other distributed system member. Other than that, all common
region configuration options are supported. A minimal declaration looks as
follows (again, the example relies on the Spring Data GemFire namespace
naming conventions to wire the cache):
<gfe:local-region id="myLocalRegion" />
Here, a local region is created (if one doesn't exist already). The
name of the region is the same as the bean id (myLocalRegion) and the bean
assumes the existence of a GemFire cache named
gemfireCache
.
One of the common region types is a replicated region or replica. In short, when a region is configured to be a replicated region, every member that hosts that region stores a copy of the region's entries 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 rep
Spring Data GemFire offers a replicated-region
element. A minimal declaration looks as follows. All common configuration
options are available for replicated regions.
<gfe:replicated-region id="simpleReplica" />
Another region type supported out of the box by the Spring Data GemFire namespace is the partitioned region. To quote the GemFire docs:
"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 is created using 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>
The following table offers a quick overview of configuration options specific to partitioned regions. These are in addition to the common region configuration options described above.
Table 5.2. partitioned-region options
Name | Values | Description |
---|---|---|
partition-resolver | bean name | The name of the partitioned resolver used by this region, for custom partitioning. |
partition-listener | bean name | The name of the partitioned listener used by this region, for handling partition events. |
copies | 0..4 | The number of copies for each partition for high-availability. By default, no copies are created meaning there is no redundancy. Each copy provides extra backup at the expense of extra storage. |
colocated-with | valid region name | The name of the partitioned region with which this newly created partitioned region is colocated. |
local-max-memory | positive integer | The maximum amount of memory, in megabytes, to be used by the region in this process. |
total-max-memory | any integer value | The maximum amount of memory, in megabytes, to be used by the region in all processes. |
recovery-delay | any long value | The delay in milliseconds that existing members will wait before satisfying redundancy after another member crashes. -1 (the default) indicates that redundancy will not be recovered after a failure. |
startup-recovery-delay | any long value | The delay in milliseconds that new members will wait before satisfying redundancy. -1 indicates that adding new members will not trigger redundancy recovery. The default is to recover redundancy immediately when a new member is added. |
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 classified in short in: peer-to-peer
(p2p), client-server, and wide area cache network (or WAN). In the last
two scenarios, it is common to declare client regions
which connect to a cache server. Spring Data GemFire offers dedicated
support for such configuration through Section 5.3.3, “Configuring a GemFire Client Cache”, client-region
and
pool
elements. As the names imply, the former defines a
client region while the latter defines connection pools to be used/shared
by the various client regions.
Below is a typical client region configuration:
<!-- 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>
As with the other region types, client-region
supports CacheListener
s
as well as a single CacheLoader
or
CacheWriter
. It also requires a connection
pool
for connecting to a server. Each client can have
its own pool or they can share the same one.
Note | |
---|---|
In the above example, the pool is configured with a
locator . The locator is a separate process used to
discover cache servers in the distributed system and are recommended for
production systems. It is also possible to configure the pool to connect
directly to one or more cache servers using the server
element. |
For a full list of options to set on the client and especially on the pool, please refer to the Spring Data GemFire schema (Appendix A, Spring Data GemFire Schema) and the GemFire documentation.
To minimize network traffic, each client can define its own 'interest', pointing out to GemFire, the data it actually needs. In Spring Data GemFire, interests can be defined for each client, both key-based and regular-expression-based types being supported; for example:
<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>
A special key ALL_KEYS
means interest is
registered for all keys (identical to a regex interest of
.*
). The receive-values
attribute
indicates whether or not the values are received for create and update
events. If true, values are received; if false, only invalidation events
are received - refer to the GemFire documentation for more
details.
Gemfire 7.0 introduced support for caching JSON documents with OQL
query support. These are stored internally as PdxInstance
types using the JSONFormatter
to perform conversion to and from JSON strings. Spring Data GemFire
provides a <gfe-data:json-region-autoproxy/>
tag to
enable a Spring
AOP component to advise appropropriate region operations,
effectively encapsulating the JSONFormatter, allowing your application to
work directly with JSON strings. In addition, Java objects written to JSON
configured regions will be automatically converted to JSON using the
Jackson ObjectMapper. Reading these values will return a JSON
string.
By default, <gfe-data:json-region-autoproxy/>
will
perform the conversion on all regions. To apply this feature to selected
regions, provide a comma delimited list of their ids via the
region-refs
attribute. Other attributes include a
pretty-print
flag (false by default) and
convert-returned-collections
. By default the results of
region operations getAll() and values() will be converted for configured
regions. This is done by creating a parallel structure in local memory.
This can incur significant overhead for large collections. Set this flag
to false to disable automatic conversion for these operation.
Note | |
---|---|
Certain region operations, specifically those that use GemFire's proprietary Region.Entry such as entries(boolean), entrySet(boolean) and getEntry() type are not targeted for AOP advice. In addition, the entrySet() method which returns a Set<java.util.Map.Entry<?,?>> is not affected. |
<gfe-data:json-region-autoproxy pretty-print="true" region-refs="myJsonRegion" convert-returned-collections="true"/>
This feature also works with seamlessly with GemfireTemplate operations, provided that the template is declared as a Spring bean. Currently native QueryService operations are not supported.
GemFire allows creation on indexes (or indices) to improve the
performance of (common) queries. Spring Data GemFire allows indecies to be
declared through the index
element:
<gfe:index id="myIndex" expression="someField" from="/someRegion"/>
Before creating an index, Spring Data GemFire will verify whether
one with the same name already exists. If it does, it will compare the
properties and if they don't match, will remove the old one to create a
new one. If the properties match, Spring Data GemFire will simply return
the index (in case it does not exist it will simply create one). To
prevent the update of the index, even if the properties do not match, set
the property override
to false.
Note that index declaration are not bound to a region but rather are
top-level elements (just like gfe:cache
). This allows
one to declare any number of indecies on any region whether they are just
created or already exist - an improvement versus the GemFire
cache.xml
. By default the index relies on the default
cache declaration but one can customize it accordingly or use a pool (if
need be) - see the namespace schema for the full set of options.
As of Release 1.2.0, Spring Data GemFire supports disk store
configuration via a top level disk-store
element.
Note | |
---|---|
Prior to Release 1.2.0,
|
<gfe:disk-store id="diskStore1" queue-size="50" auto-compact="true"
max-oplog-size="10" time-interval="9999">
<gfe:disk-dir location="/gemfire/store1/" max-size="20"/>
<gfe:disk-dir location="/gemfire/store2/" max-size="20"/>
</gfe:disk-store>
Disk stores are used by regions for file system persistent backup or overflow storage of evicted entries, and persistent backup of WAN gateways. Note that multiple components may share the same disk store. Also multiple directories may be defined for a single disk store. Please refer to the GemFire documentation for an explanation of the configuration options.
As of Release 1.3.0, Spring Data GemFire provides annotation support
for implementing and registering functions. Spring Data GemFire also provides
namespace support for registering GemFire Functions
for remote
function execution. Please refer to the GemFire documentation for more
information on the function execution framework. Functions are declared as
Spring beans and must implement the
com.gemstone.gemfire.cache.execute.Function
interface or extend
com.gemstone.gemfire.cache.execute.FunctionAdapter
.
The namespace uses a familiar pattern to declare functions:
<gfe:function-service> <gfe:function> <bean class="com.company.example.Function1"/> <ref bean="function2"/> </gfe:function> </gfe:function-service> <bean id="function2" class="com.company.example.Function2"/>
WAN gateways provide a way to synchronize GemFire distributed systems across geographic distributed areas. As of Release 1.2.0, Spring Data GemFire provides namespace support for configuring WAN gateways as illustrated in the following examples:
GemFire 7.0 introduces new APIs for WAN configuration. While the original APIs provided
in GemFire 6 are still supported, it is recommended that you use the new
APIs if you are using GemFire 7.0. The Spring Data GemFire namespace
supports either. In the example below, GatewaySender
s are configured for a
partitioned region by adding child elements to the region (gateway-sender
and gateway-sender-ref
). The GatewaySender
may register
EventFilter
s and
TransportFilters
. Also shown below is an example configuration of an
AsyncEventQueue
which must also be wired into a region (not shown).
<gfe:partitioned-region id="region-inner-gateway-sender" > <gfe:gateway-sender remote-distributed-system-id="1"> <gfe:event-filter> <bean class="org.springframework.data.gemfire.example.SomeEventFilter"/> </gfe:event-filter> <gfe:transport-filter> <bean class="org.springframework.data.gemfire.example.SomeTransportFilter"/> </gfe:transport-filter> </gfe:gateway-sender> <gfe:gateway-sender-ref bean="gateway-sender"/> </gfe:partitioned-region> <gfe:async-event-queue id="async-event-queue" batch-size="10" persistent="true" disk-store-ref="diskstore" maximum-queue-memory="50"> <gfe:async-event-listener> <bean class="org.springframework.data.gemfire.example.SomeAsyncEventListener"/> </gfe:async-event-listener> </gfe:async-event-queue> <gfe:gateway-sender id="gateway-sender" remote-distributed-system-id="2"> <gfe:event-filter> <ref bean="event-filter"/> <bean class="org.springframework.data.gemfire.example.SomeEventFilter"/> </gfe:event-filter> <gfe:transport-filter> <ref bean="transport-filter"/> <bean class="org.springframework.data.gemfire.example.SomeTransportFilter"/> </gfe:transport-filter> </gfe:gateway-sender> <bean id="event-filter" class="org.springframework.data.gemfire.example.AnotherEventFilter"/> <bean id="transport-filter" class="org.springframework.data.gemfire.example.AnotherTransportFilter"/>
On the other end of a GatewaySender
is a corresponding
GatewayReceiver
to receive gateway events. The GatewayReceiver
may also be configured with
EventFilter
s and TransportFilter
s.
<gfe:gateway-receiver id="gateway-receiver" start-port="12345" end-port="23456" bind-address="192.168.0.1"> <gfe:transport-filter> <bean class="org.springframework.data.gemfire.example.SomeTransportFilter"/> </gfe:transport-filter> </gfe:gateway-receiver>
Please refer to the GemFire product document for a detailed explanation of all the configuration options.
<gfe:cache/> <gfe:replicated-region id="region-with-gateway" enable-gateway="true" hub-id="gateway-hub"/> <gfe:gateway-hub id="gateway-hub" manual-start="true"> <gfe:gateway gateway-id="gateway"> <gfe:gateway-listener> <bean class="com.company.example.MyGatewayListener"/> </gfe:gateway-listener> <gfe:gateway-queue maximum-queue-memory="5" batch-size="3" batch-time-interval="10" /> </gfe:gateway> <gfe:gateway gateway-id="gateway2"> <gfe:gateway-endpoint port="1234" host="host1" endpoint-id="endpoint1"/> <gfe:gateway-endpoint port="2345" host="host2" endpoint-id="endpoint2"/> </gfe:gateway> </gfe:gateway-hub>
A region may synchronize all or part of its contents to a gateway
hub used to access one or more remote systems. The region must set
enable-gateway
to true
and specify
the hub-id
.
Note | |
---|---|
If just a hub-id is specified, Spring Data GemFire automatically assumes that the gateway should be enabled. |
Please refer to the GemFire product document for a detailed explanation of all the configuration options.
Once the GemFire Cache and Regions have been configured they can be injected and used inside application objects.
This chapter describes the integration with Spring's Transaction Management functionality
and DaoException
hierarchy. It also covers support for dependency injection
of GemFire managed objects.
Using a new data access technology requires not only accommodating a new API but also handling exceptions
specific to that technology. To accommodate this case, Spring Framework provides a technology agnostic,
consistent exception hierarchy
that abstracts the application from proprietary (and usually checked) exceptions to a set of focused
runtime exceptions. As mentioned in the Spring Framework documentation,
exception translation
can be applied transparently to your data access objects through the use of the @Repository
annotation and AOP by defining a PersistenceExceptionTranslationPostProcessor
bean.
The same exception translation functionality is enabled when using GemFire as long as at least a
CacheFactoryBean
is declared, e.g. using a <gfe:cache/>
declaration, as it acts as an exception translator which is automatically detected by the
Spring infrastructure and used accordingly.
As with many other high-level abstractions provided by the Spring projects, Spring Data GemFire provides a
template that simplifies GemFire data access. The class provides several
one-line methods, for common region operations but also the ability to
execute code against the native GemFire API without having to deal with GemFire
checked exceptions for example through the GemfireCallback
.
The template class requires a GemFire Region
instance and once configured is
thread-safe and should be reused across multiple classes:
<bean id="gemfireTemplate" class="org.springframework.data.gemfire.GemfireTemplate" p:region-ref="someRegion"/>
Once the template is configured, one can use it alongside GemfireCallback
to work directly with the GemFire Region
, without having to deal with
checked exceptions, threading or resource management concerns:
template.execute(new GemfireCallback<Iterable<String>>() { public Iterable<String> doInGemfire(Region reg) throws GemFireCheckedException, GemFireException { // working against a Region of String Region<String, String> region = reg; region.put("1", "one"); region.put("3", "three"); return region.query("length < 5"); } });
For accessing the full power of the GemFire query language, one can use the find
and findUnique
which, as opposed to the query
method,
can execute queries across multiple regions, execute projections, and the like. The find
method should be used when the query selects multiple items (throughSelectResults
)
and the latter, findUnique
, as the name suggests, when only one object is returned.
Since 1.1, Spring Data GemFire provides an implementation of the Spring 3.1
cache abstraction.
To use GemFire as a backing implementation, simply add GemfireCacheManager
to your
configuration:
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:cache="http://www.springframework.org/schema/cache" xmlns:gfe="http://www.springframework.org/schema/gemfire" xmlns:p="http://www.springframework.org/schema/p" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 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 http://www.springframework.org/schema/cache http://www.springframework.org/schema/cache/spring-cache.xsd"> <!-- turn on declarative caching --> <cache:annotation-driven/> <gfe:cache id="gemfire-cache"/> <!-- declare GemFire Cache Manager --> <bean id="cacheManager" class="org.springframework.data.gemfire.support.GemfireCacheManager" p:cache-ref="gemfire-cache"> </beans>
One of the most popular features of Spring Framework is transaction management. If you are not familiar with it, we strongly recommend reading about it as it offers a consistent programming model that works transparently across multiple APIs and can be configured either programmatically or declaratively (the most popular choice).
For GemFire, Spring Data GemFire provides a dedicated, per-cache, transaction manager that, once declared, allows Region operations to be executed atomically through Spring:
<gfe:transaction-manager id="tx-manager" cache-ref="cache"/>
Note | |
---|---|
The example above can be simplified even more by eliminating the cache-ref attribute
if the GemFire Cache is defined under the default namegemfireCache . As with the other
Spring Data GemFire namespace elements, if the Cache bean name is not configured, the aforementioned naming
convention will used. Additionally, the transaction manager name isgemfireTransactionManager
if not explicitly specified.
|
Currently, GemFire supports optimistic transactions with read committed isolation.
Furthermore, to guarantee this isolation, developers should avoid making in-place changes
that manually modify values present in the Cache. To prevent this from happening, the transaction manager
configures the Cache to use copy on read semantics, meaning a clone of the actual value
is created, each time a read is performed. This behavior can be disabled if needed through the
copyOnRead
property. For more information on the semantics of the underlying GemFire
transaction manager, see the GemFire
documentation.
A powerful functionality offered by GemFire is
continuous querying (or CQ).
In short, CQ allows one to create a query and automatically be notified when new data that gets added to GemFire matches the query.
Spring GemFire provides dedicated support for CQs through the org.springframework.data.gemfire.listener
package and
its listener container; very similar in functionality
and naming to the JMS integration in Spring Framework; in fact, users familiar with the JMS support in Spring, should
feel right at home. Basically Spring Data GemFire allows methods on POJOs to become end-points for CQ - simply define the query and indicate the method
that should be notified when there is a match - Spring Data GemFire takes care of the rest. This is similar Java EE's message-driven bean style, but without any
requirement for base class or interface implementations, based on GemFire.
Note | |
---|---|
Currently, continuous queries are supported by GemFire only in client/server topologies. Additionally the pool used is required to have the
|
Spring Data GemFire simplifies the creation, registration, life-cycle and dispatch of CQs by taking care of the infrastructure around them through
ContinuousQueryListenerContainer
which does all the heavy lifting on behalf of the user -
users familiar with EJB and JMS should find the concepts familiar as it is designed as close as possible to the
support in Spring Framework and its message-driven POJOs (MDPs)
ContinuousQueryListenerContainer
acts as an event (or message) listener container; it is used to receive the events
from the registered CQs and drive the POJOs that are injected into it. The listener container is responsible for all threading of message
reception and dispatches into the listener for processing. It acts as the intermediary between an EDP (Event Driven POJO) and the event provider
and takes care of creation and registration of CQs (to receive events), resource acquisition and release, exception conversion and the like.
This allows you as an application developer to write the (possibly complex) business logic associated with receiving an event (and reacting to it),
and delegates boilerplate GemFire infrastructure concerns to the framework.
The container is fully customizable - one can chose either to use the CQ thread to perform the dispatch (synchronous delivery) or a new thread
(from an existing pool for examples) for an asynchronous approach by defining the suitable java.util.concurrent.Executor
(or Spring's TaskExecutor
). Depending on the load, the number of listeners or the runtime
environment, one should change or tweak the executor to better serve her needs - in particular in managed environments (such as app servers), it is
highly recommended to pick a a proper TaskExecutor
to take advantage of its runtime.
The ContinuousQueryListenerAdapter
class is the
final component in Spring Data GemFire CQ support: in a nutshell, it allows you to expose almost any class
as a EDP (there are of course some constraints) - it implements ContinuousQueryListener
, a simpler listener interface
similar to GemFire CqListener.
Consider the following interface definition. Notice the various event handling methods and their parameters:
public interface EventDelegate { void handleEvent(CqEvent event); void handleEvent(Operation baseOp); void handleEvent(Object key); void handleEvent(Object key, Object newValue); void handleEvent(Throwable th); void handleQuery(CqQuery cq); void handleEvent(CqEvent event, Operation baseOp, byte[] deltaValue); void handleEvent(CqEvent event, Operation baseOp, Operation queryOp, Object key, Object newValue); }
public class DefaultEventDelegate implements EventDelegate { // implementation elided for clarity... }
In particular, note how the above implementation of the
EventDelegate
interface (the above
DefaultEventDelegate
class) has
no GemFire dependencies at all. It truly is a POJO that
we will make into an EDP via the following configuration (note that the class doesn't have to implement an interface,
one is present only to better show case the decoupling between contract and implementation).
<?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 pool-name="client"/> <gfe:pool id="client" subscription-enabled="true"> <gfe:server host="localhost" port="40404"/> </gfe:pool> <gfe:cq-listener-container> <!-- default handle method --> <gfe:listener ref="listener" query="SELECT * from /region"/ > <gfe:listener ref="another-listener" query="SELECT * from /another-region" name="my-query" method="handleQuery"/> </gfe:cq-listener-container> <bean id="listener" class="gemfireexample.DefaultMessageDelegate"/> <bean id="another-listener" class="gemfireexample.DefaultMessageDelegate"/> ... <beans>
Note | |
---|---|
The example above shows some of the various forms that a listener can have; at its minimum the listener reference and the actual query definition are required. It's possible however to specify
a name for the resulting continuous query (useful for monitoring) but also the name of the method (the default is handleEvent ). The specified method can have various
argument types, the EventDelegate interface lists the allowed types. |
The example above uses the Spring Data GemFire namespace to declare the event listener container and automatically register the listeners. The full blown, beans definition is displayed below:
<!-- this is the Event Driven POJO (MDP) --> <bean id="eventListener" class="org.springframework.data.gemfire.listener.adapter.ContinuousQueryListenerAdapter"> <constructor-arg> <bean class="gemfireexample.DefaultEventDelegate"/> </constructor-arg> </bean> <!-- and this is the event listener container... --> <bean id="gemfireListenerContainer" class="org.springframework.data.gemfire.listener.ContinuousQueryListenerContainer"> <property name="cache" ref="gemfireCache"/> <property name="queryListeners"> <!-- set of listeners --> <set> <bean class="org.springframework.data.gemfire.listener.ContinuousQueryDefinition" > <constructor-arg value="SELECT * from /region" /> <constructor-arg ref="eventListener" /> </bean> </set> </property> </bean>
Each time an event is received, the adapter automatically performs type translation between the GemFire event and the required method argument(s) transparently. Any exception caused by the method invocation is caught and handled by the container (by default, being logged).
GemFire XML configuration (usually named
cache.xml
allows user objects to
be declared as part of the configuration. Usually these objects are
CacheLoader
s or other pluggable callback components
supported by GemFire. Using native GemFire configuration, each user type declared through
XML must implement the Declarable
interface
which allows arbitrary parameters to be passed to the declared class
through a Properties
instance.
In this section we describe how you can configure these pluggable
components defined in cache.xml
using Spring while
keeping your Cache/Region configuration defined in
cache.xml
This allows your pluggable components to
focus on the application logic and not the location or creation of
DataSources or other collaboration objects.
However, if you are starting a green field project, it is
recommended that you configure Cache, Region, and other pluggable
components directly in Spring. This avoids inheriting from the
Declarable
interface or the base class
presented in this section. See the following sidebar for more information
on this approach.
As an example of configuring a
Declarable
component using Spring, consider
the following declaration (taken from the
Declarable
javadoc):
<cache-loader> <class-name>com.company.app.DBLoader</class-name> <parameter name="URL"> <string>jdbc://12.34.56.78/mydb</string> </parameter> </cache-loader>
To simplify the task of parsing, converting the parameters and
initializing the object, Spring Data GemFire offers a base class
(WiringDeclarableSupport
) that allows GemFire user
objects to be wired through a template bean
definition or, in case that is missing, perform autowiring through the
Spring container. To take advantage of this feature, the user objects need
to extend WiringDeclarableSupport
which
automatically locates the declaring
BeanFactory
and performs wiring as part of
the initialization process.
When used, WiringDeclarableSupport
tries to
first locate an existing bean definition and use that as wiring
template. Unless specified, the component class name will be used as an
implicit bean definition name. Let's see how our
DBLoader
declaration would look in that
case:
public class DBLoader extends WiringDeclarableSupport implements CacheLoader { private DataSource dataSource; public void setDataSource(DataSource ds){ this.dataSource = ds; } public Object load(LoaderHelper helper) { ... } }
<cache-loader> <class-name>com.company.app.DBLoader</class-name> <!-- no parameter is passed (use the bean implicit name that is the class name) --> </cache-loader>
<?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"> <bean id="dataSource" ... /> <!-- template bean definition --> <bean id="com.company.app.DBLoader" abstract="true" p:dataSource-ref="dataSource"/> </beans>
In the scenario above, as no parameter was specified, a bean with
the id/name com.company.app.DBLoader
was used as a template
for wiring the instance created by GemFire. For cases where the bean name uses a different
convention, one can pass in the bean-name
parameter
in the GemFire configuration:
<cache-loader> <class-name>com.company.app.DBLoader</class-name> <!-- pass the bean definition template name as parameter --> <parameter name="bean-name"> <string>template-bean</string> </parameter> </cache-loader>
<?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"> <bean id="dataSource" ... /> <!-- template bean definition --> <bean id="template-bean" abstract="true" p:dataSource-ref="dataSource"/> </beans>
Note | |
---|---|
The template bean definitions do not have to be declared in XML - any format is allowed (Groovy, annotations, etc..). |
If no bean definition is found, by default,
WiringDeclarableSupport
will autowire
the declaring instance. This means that unless any dependency injection
metadata is offered by the instance, the container
will find the object setters and try to automatically satisfy these
dependencies. However, one can also use JDK 5 annotations to provide
additional information to the auto-wiring process. We strongly recommend
reading the dedicated chapter
in the Spring documentation for more information on the supported
annotations and enabling factors.
For example, the hypothetical DBLoader
declaration above can be injected with a Spring-configured
DataSource in the following way:
public class DBLoader extends WiringDeclarableSupport implements CacheLoader { // use annotations to 'mark' the needed dependencies @javax.inject.Inject private DataSource dataSource; public Object load(LoaderHelper helper) { ... } }
<cache-loader> <class-name>com.company.app.DBLoader</class-name> <!-- no need to declare any parameters anymore since the class is auto-wired --> </cache-loader>
<?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:context="http://www.springframework.org/schema/context" xsi:schemaLocation="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"> <!-- enable annotation processing --> <context:annotation-config/> </beans>
By using the JSR-330 annotations, the cache loader code has been
simplified since the location and creation of the DataSource has been
externalized and the user code is concerned only with the loading
process. The DataSource
might be
transactional, created lazily, shared between multiple objects or
retrieved from JNDI - these aspects can be easily configured and changed
through the Spring container without touching the
DBLoader
code.
To improve overall performance of the data grid, GemFire supports a dedicated serialization protocol (PDX) that is both faster and offers more compact results over the standard Java serialization and works transparently across various language platforms (such as Java, .NET and C++). This chapter discusses the various ways in which Spring Data GemFire simplifies and improves GemFire custom serialization in Java.
It is fairly common for serialized objects to have transient data.
Transient data is often dependent on the node or environment where it
lives at a certain point in time, for example a DataSource. Serializing
such information is useless (and potentially even dangerous) since it is
local to a certain VM/machine. For such cases, Spring Data GemFire offers a special Instantiator
that performs wiring for each new instance created by GemFire during
deserialization.
Through such a mechanism, one can rely on the Spring container to
inject (and manage) certain dependencies making it easy to split transient
from persistent data and have rich domain objects in
a transparent manner (Spring users might find this approach similar to
that of @Configurable
).
The WiringInstantiator
works just like
WiringDeclarableSupport
, trying to first locate a
bean definition as a wiring template and following to autowiring
otherwise. Please refer to the previous section (Section 6.6, “Wiring Declarable
components”) for more details on wiring
functionality.
To use this Instantiator
, simply declare it
as a usual bean:
<bean id="instantiator" class="org.springframework.data.gemfire.serialization.WiringInstantiator"> <!-- DataSerializable type --> <constructor-arg>org.pkg.SomeDataSerializableClass</constructor-arg> <!-- type id --> <constructor-arg>95</constructor-arg> </bean>
During the container startup, once it is being initialized, the
instantiator
will, by default, register itself with the
GemFire system and perform wiring on all instances of
SomeDataSerializableClass
created by GemFire during
deserialization.
For data intensive applications, a large number of instances might
be created on each machine as data flows in. Out of the box, GemFire uses
reflection to create new types but for some scenarios, this might prove to
be expensive. As always, it is good to perform profiling to quantify
whether this is the case or not. For such cases, Spring Data GemFire allows the automatic
generation of Instatiator
classes which instantiate
a new type (using the default constructor) without the use of
reflection:
<bean id="instantiator-factory" class="org.springframework.data.gemfire.serialization.InstantiatorFactoryBean"> <property name="customTypes"> <map> <entry key="org.pkg.CustomTypeA" value="1025"/> <entry key="org.pkg.CustomTypeB" value="1026"/> </map> </property> </bean>
The definition above, automatically generated two
Instantiator
s for two classes, namely
CustomTypeA
and CustomTypeB
and registers them with GemFire, under user id 1025
and
1026
. The two instantiators avoid the use of reflection
and create the instances directly through Java code.
Spring Data GemFire provides support to map entities that will be stored in a GemFire data grid. The mapping metadata is defined using annotations at the domain classes just like this:
Example 8.1. Mapping a domain class to a GemFire Region
@Region("People") public class Person { @Id Long id; String firstname; String lastname; @PersistenceConstructor public Person(String firstname, String lastname) { // … } … }
The first thing you see here is the @Region
annotation that can be used to
customize the Region in which the Person
class is stored in. The
@Id
annotation can be used to annotate the property that shall be used as
the Cache key. The @PersistenceConstructor
annotation actually helps
disambiguating multiple potentially available constructors taking parameters and explicitly marking the one
annotated as the one to be used to create entities. With none or only a single constructor you can omit the
annotation.
In addition to storing entities in top-level Regions, entities can be stored in GemFire Sub-Regions, as so:
@Region("/Users/Admin") public class Admin extends User { … } @Region("/Users/Guest") public class Guest extends User { ... }
Be sure to use the full-path of the GemFire Region, as defined in Spring Data GemFire XML namespace
configuration meta-data, as specified in the id
or name
attributes
of the <*-region>
bean definition.
As alternative to specifying the Region in which the entity will be stored using the
@Region
annotation on the entity class, you can also specify the
@Region
annotation on the entity's Repository
abstraction. See Chapter 9, GemFire Repositories for more details.
However, let's say you want to store a Person in multiple GemFire Regions (e.g. People
and Customers
), then you can define your corresponding Repository
interface abstractions like so:
@Region("People") public interface PersonRepository extends GemfireRepository<Person, String> { … } @Region("Customers") public interface CustomerRepository extends GemfireRepository<Person, String> { ... }
Spring Data GemFire provides a custom
PDXSerializer
implementation that uses the
mapping information to customize entity serialization. Beyond that it
allows customizing the entity instantiation by using the Spring Data
EntityInstantiator
abstraction. By default
the serializer uses a ReflectionEntityInstantiator
that will use the persistence constructor of the mapped entity (either the
single declared one or explicitly annoted with
@PersistenceConstructor
). To provide values
for constructor parameters it will read fields with name of the
constructor parameters from the PDXReader
supplied.
Example 8.2. Using @Value on entity constructor parameters
public class Person { public Person(@Value("#root.foo") String firstname, @Value("bean") String lastname) { // … } }
The entity annotated as such will get the field foo
read from the PDXReader
and handed as
constructor parameter value for firstname
. The value for
lastname
will be the Spring bean with name
bean
.
Spring Data GemFire provides support to use the Spring Data repository abstraction to easily persist entities into GemFire and execute queries. A general introduction into the repository programming model is been provided here .
To bootstrap Spring Data repositories you use the
<repositories />
element from the GemFire
namespace:
Example 9.1. Bootstrap GemFire repositories
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:gfe-data="http://www.springframework.org/schema/data/gemfire" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/data/gemfire http://www.springframework.org/schema/data/gemfire/spring-data-gemfire.xsd> <gfe-data:repositories base-package="com.acme.repository" /> </beans>
This configuration snippet will look for interfaces below the
configured base package and create repository instances for those
interfaces backed by a SimpleGemFireRepository
.
Note that you have to have your domain classes correctly mapped to
configured regions as the bottstrap process will fail otherwise.
The GemFire repositories allow the definition of query methods to easily execute OQL queries against the Region the managed entity is mapped to.
Example 9.2. Sample repository
@Region("myRegion") public class Person { … }
public interface PersonRepository extends CrudRepository<Person, Long> { Person findByEmailAddress(String emailAddress); Collection<Person> findByFirstname(String firstname); @Query("SELECT * FROM /Person p WHERE p.firstname = $1") Collection<Person> findByFirstnameAnnotated(String firstname); @Query("SELECT * FROM /Person p WHERE p.firstname IN SET $1") Collection<Person> findByFirstnamesAnnotated(Collection<String> firstnames); }
The first method listed here will cause the following query to be
derived: SELECT x FROM /myRegion x WHERE x.emailAddress = $1
.
The second method works the same way except it's returning all entities
found whereas the first one expects a single result value. In case the
supported keywords are not sufficient to declare your query or the method
name gets to verbose you can annotate the query methods with
@Query
as seen for methods 3 and 4.
Table 9.1. Supported keywords for query methods
Keyword | Sample | Logical result |
---|---|---|
GreaterThan | findByAgeGreaterThan(int
age) | x.age > $1 |
GreaterThanEqual | findByAgeGreaterThanEqual(int
age) | x.age >= $1 |
LessThan | findByAgeLessThan(int
age) | x.age < $1 |
LessThanEqual | findByAgeLessThanEqual(int
age) | x.age <= $1 |
IsNotNull ,
NotNull | findByFirstnameNotNull() | x.firstname =! NULL |
IsNull ,
Null | findByFirstnameNull() | x.firstname = NULL |
In | findByFirstnameIn(Collection<String>
x) | x.firstname IN SET $1 |
NotIn | findByFirstnameNotIn(Collection<String>
x) | x.firstname NOT IN SET $1 |
(No keyword) | findByFirstname(String
name) | x.firstname = $1 |
Like | findByFirstnameLike(String
name) | x.firstname LIKE $1 |
Not | findByFirstnameNot(String
name) | x.firstname != $1 |
IsTrue ,
True | findByActiveIsTrue() | x.active = true |
IsFalse ,
False | findByActiveIsFalse() | x.active = false |
Spring Data GemFire 1.3.0 introduces annotation support to simplify working with GemFire function execution. The GemFire API provides classes to implement and register Functions deployed to cache servers that may be invoked remotely by member applications, typically cache clients. Functions may execute in parallel, distributed among multiple servers, combining results in a map-reduce pattern, or may be targeted to a single server. A Function execution may be also be targeted to a specific region.
GemFire's also provides APIs to support remote execution of functions targeted to various defined scopes (region, member groups, servers, etc.) and the ability to aggregate results. The API also provides certain runtime options. The implementation and execution of remote functions, as with any RPC protocol, requires some boilerplate code. Spring Data GemFire, true to Spring's core value proposition, aims to hide the mechanics of remote function execution and allow developers to focus on POJO programming and business logic. To this end, Spring Data GemFire introduces annotations to declaratively register public methods as functions, and the ability to invoke registered functions remotely via annotated interfaces.
There are two separate concerns to address. First is the function implementation (server) which must interact with the FunctionContext to obtain the invocation arguments, the ResultsSender and other execution context information. The function implementation typically accesses the Cache and or Region and is typically registered with the FunctionService under a unique Id. The application invoking a function (the client) does not depend on the implementation. To invoke a function remotely, the application instantiates an Execution providing the function ID, invocation arguments, the function target or scope (region, server, servers, member, members). If the function produces a result, the invoker uses a ResultCollector to aggregate and acquire the execution results. In certain scenarios, a custom ResultCollector implementation is required and may be registered with the Execution.
Note | |
---|---|
'Client' and 'Server' are used here in the context of function execution which may have a different meaning then client and server in a client-server cache topology. While it is common for a member with a Client Cache to invoke a function on one or more Cache Server members it is also possible to execute functions in a peer-to-peer configuration |
Using GemFire APIs, the FunctionContext provides a runtime invocation context including the client's calling arguments and a ResultSender interface to send results back to the client. Additionally, if the function is executed on a Region, the FunctionContext is an instance of RegionFunctionContext which provides additional context such as the target Region and any Filter (set of specific keys) associated with the Execution. If the Region is a Partition Region, the function should use the PartitonRegionHelper to extract only the local data.
Using Spring, one can write a simple POJO and enable the Spring container bind one or more of it's public methods to a Function. The signature for a POJO method intended to be used as a function must generally conform to the the client's execution arguments. However, in the case of a region execution, the region data must also be provided (presumably the data held in the local partition if the region is a partition region). Additionally the function may require the filter that was applied, if any. This suggests that the client and server may share a contract for the calling arguments but that the method signature may include additional parameters to pass values provided by the FunctionContext. One possibility is that the client and server share a common interface, but this is not required. The only constraint is that the method signature includes the same sequence of calling arguments with which the function was invoked after the additional parameters are resolved. For example, suppose the client provides a String and int as the calling arguments. These are provided by the FunctionContext as an array:
Object[] args = new Object[]{"hello",
123}
Then the Spring container should be able to bind to any method signature similar to the following. Let's ignore the return type for the moment:
public Object method1(String s1, int i2) {...} public Object method2(Map<?,?> data, String s1, int i2) {...} public Object method3(String s1, Map<?,?>data, int i2) {...} public Object method4(String s1, Map<?,?> data, Set<?> filter, int i2) {...} public void method4(String s1, Set<?> filter, int i2, Region<?,?> data) {...} public void method5(String s1, ResultSender rs, int i2); public void method6(FunctionContest fc);
The general rule is that once any additional arguments, i.e., region data and filter, are resolved the remaining arguments must correspond exactly, in order and type, to the expected calling parameters. The method's return type must be void or a type that may be serialized (either java.io.Serializable, DataSerializable, or PDX serializable). The latter is also a requirement for the calling arguments. The Region data should normally be defined as a Map, to facilitate unit testing, but may also be of type Region if necessary. As shown in the example above, it is also valid to pass the FunctionContext itself, or the ResultSender, if you need to control how the results are returned to the client.
The following example illustrates how annotations are used to expose a POJO as a GemFire function:
@Component public class MyFunctions { @GemfireFunction public String function1(String s1, @RegionData Map<?,?> data, int i2) { ... } @GemfireFunction("myFunction", HA=true, optimizedForWrite=true, batchSize=100) public List<String> function2(String s1, @RegionData Map<?,?> data, int i2, @Filter Set<?> keys) { ... } @GemfireFunction(hasResult=true) public void functionWithContext(FunctionContext functionContext) { ... } }
Note that the class itself must be registered as a Spring
bean. Here the @Component
annotation is used, but you
may register the bean by any method provided by Spring (e.g. XML
configuration or Java configuration class). This allows the Spring
container to create an instance of this class and wrap it in a PojoFunctionWrapper(PFW).
Spring creates one PFW instance for each method annotated with
@GemfireFunction
. Each will all share the same target
object instance to invoke the corresponding method.
Note | |
---|---|
The fact that the function class is a Spring bean may offer other benefits since it shares the application context with GemFire components such as a Cache and Regions. These may be injected into the class if necessary. |
Spring creates the wrapper class, and registers the function with
GemFire's Function Service. The function id used to register the
functions must be unique. By convention it defaults to the simple
(unqualified) method name. Note that this annotation also provides
configuration attributes, HA
and
optimizedForWrite
which correspond to properties
defined by GemFire's Function interface. If the method's return type is
void, then the hasResult
property is automatically
set to false
; otherwise it is
true
.
For void
return types, the annotation provides
a hasResult
attribute that can be set to true to
override this convention, as shown in the
functionWithContext
method above. Presumably, the
intention is to use the ResultSender directly to send results to the
caller.
The PFW implements GemFire's Function interface, binds the method
parameters, and invokes the target method in its
execute()
method. It also sends the method's return
value using the ResultSender.
If the return type is a Collection or Array, then some
consideration must be given to how the results are returned. By
default, the PFW returns the entire collection at once. If the number
of items is large, this may incur a performance penalty. To divide the
payload into small sections (sometimes called chunking), you can set
the batchSize
attribute, as illustrated in
function2
, above.
Note | |
---|---|
If you need more control of the ResultSender, especially if the method itself would use too much memory to create the collection, you can pass the ResultSender, or access it via the FunctionContext, to use it directly within the method. |
A process invoking a remote function needs to provide calling arguments, a function id, the execution target (onRegion, onServers, onServer, onMember, onMembers) and optionally a Filter set. All you need to do is define an interface supported by annotations. Spring will create a dynamic proxy the interface which will use the FunctionService to create an Execution, invoke the execution and coerce the results to a defined return type, if necessary. This technique is very similar to the way Spring Data repositories work, thus some of the configuration and concepts should be familiar. Generally a single interface definition maps to multiple function executions, one corresponding to each method defined in the interface.
To support client side function execution, the following
annotations are provided: @OnRegion
,
@OnServer
, @OnServers
,
@OnMember
, @OnMembers
. These
correspond to the Execution implementations GemFire's FunctionService
provides. Each annotation exposes the appropriate attributes. These
annotations also provide an optional resultCollector
attribute whose value is the name of a Spring bean implementing ResultCollector
to use for the execution.
Note | |
---|---|
The proxy interface binds all declared methods to the same execution configuration. Although it is expected that single method interfaces will be common, all methods in the interface are backed by the same proxy instance and therefore are all share the same configuration. |
Here are some examples:
@OnRegion(region="someRegion", resultCollector="myCollector") public interface FunctionExecution { @FunctionId("function1") public String doIt(String s1, int i2); public String getString(Object arg1, @Filter Set<Object> keys) ; }
By default, the function id is the simple (unqualified) method
name. @FunctionId
is used to bind this invocation to
a different function id.
The client side uses Spring's component scanning capability to discover annotated interfaces. To enable function execution annotation processing, you can use XML:
<gfe-data:function-executions base-package="org.example.myapp.functions"/>
Note that the function-executions
tag is
provided in the gfe-data
namespace. The
base-package
attribute is required to avoid
scanning the entiire class path. Additional filters are provided as
described in the Spring reference.
Or annotate your Java configuration class:
@EnableGemfireFunctionExecutions(basePackages = "org.example.myapp.functions")
Using the annotated interface as described in the previous section, simply wire your interface into a bean that will invoke the function:
@Component public class MyApp { @Autowired FunctionExecution functionExecution; public void doSomething() { functionExecution.doIt("hello", 123); } }
Alternately, you can use a Function Execution template directly. For example GemfireOnRegionFunctionTemplate creates an onRegion execution. For example:
Set<?,?> myFilter = getFilter(); Region<?,?> myRegion = getRegion(); GemfireOnRegionOperations template = new GemfireOnRegionFunctionTemplate(myRegion); String result = template.executeAndExtract("someFunction",myFilter,"hello","world",1234);
Internally,
function executions always return a List.
executeAndExtract
assumes a singleton list containing
the result and will attempt to coerce that value into the requested type.
There is also an execute
method that returns the List
itself. The first parameter is the function id. The filter argument is
optional. The following arguments are a variable argument list.
Normally, a Spring-based application will bootstrap GemFire using
Spring Data GemFire's XML namespace. Just by specifying a <gfe:cache/>
element
in Spring Data GemFire configuration meta-data, a single, peer GemFire Cache instance will be created
and initialized with default settings in the same JVM process as your application.
However, sometimes it is a requirement, perhaps imposed by your IT operations team, that GemFire must be fully managed and operated using the provided GemFire tool suite, such as with Gfsh. Using Gfsh, even though the application and GemFire will share the same JVM process, GemFire will bootstrap your Spring application context rather than the other way around. So, using this approach GemFire, instead of an application server, or a Java main class using Spring Boot, will bootstrap and host your application.
Keep in mind, however, that GemFire is not an application server. In addition, there are limitations to using this approach where GemFire Cache configuration is concerned.
In order to bootstrap a Spring application context in GemFire when starting a GemFire Server process using Gfsh, a user must make use of GemFire's Initalizer functionality. An Initializer can be used to specify a callback application that is launched after the Cache is initialized by GemFire.
An Initializer is specified within an
initializer
element using a minimal snippet of GemFire's native configuration meta-data inside
a cache.xml
file. The cache.xml
file is required in order to
bootstrap the Spring application context, much like a minimal snippet of Spring XML config is needed to
bootstrap a Spring application context configured with component scanning
(e.g. <context:component-scan base-packages="..."/>
)
As of Spring Data GemFire 1.4, such an Initializer is already conveniently provided
by the framework, the org.springframework.data.gemfire.support.SpringContextBootstrappingInitializer
.
The typical, yet minimal configuration for this class inside GemFire's cache.xml
file
will look like the following:
<?xml version="1.0"?> <!DOCTYPE cache PUBLIC "-//GemStone Systems, Inc.//GemFire Declarative Caching 7.0//EN" "http://www.gemstone.com/dtd/cache7_0.dtd"> <cache> <initializer> <class-name>org.springframework.data.gemfire.support.SpringContextBootstrappingInitializer</class-name> <parameter name="contextConfigLocations"> <string>classpath:application-context.xml</string> </parameter> </initializer> </cache>
The SpringContextBootstrappingInitializer
class follows similar conventions as
Spring's ContextLoaderListener class for bootstrapping a Spring context inside a Web Application, where
application context configuration files are specified with the contextConfigLocations
Servlet Context Parameter. In addition, the SpringContextBootstrappingInitializer
class can also be used with a basePackages
parameter to specify a comma-separated list
of base package containing the appropriately annotated application components that the Spring container
will search using component scanning and create Spring beans for:
<?xml version="1.0"?> <!DOCTYPE cache PUBLIC "-//GemStone Systems, Inc.//GemFire Declarative Caching 7.0//EN" "http://www.gemstone.com/dtd/cache7_0.dtd"> <cache> <initializer> <class-name>org.springframework.data.gemfire.support.SpringContextBootstrappingInitializer</class-name> <parameter name="basePackages"> <string>org.mycompany.myapp.services,org.mycompany.myapp.dao,...</string> </parameter> </initializer> </cache>
Then, with a properly configured and constructed CLASSPATH
along with the
cache.xml
file shown above specified as a command-line option when starting
a GemFire Server in Gfsh, the command-line would be:
gfsh>start server --name=Server1 --log-level=config ... --classpath="/path/to/spring-data-gemfire-1.4.0.jar:/path/to/application/classes.jar" --cache-xml-file="/path/to/gemfire/cache.xml"
The application-context.xml
can be any valid Spring context configuration meta-data
including all the SDG namespace elements. The only limitation with this approach is that the GemFire
Cache cannot be configured using the Spring Data GemFire namespace. In other words, none of the
<gfe:cache/>
element attributes, such as cache-xml-location
,
properties-ref
, critical-heap-percentage
, pdx-serializer-ref
,
lock-lease
, etc can be specified. If used, these attributes will be ignored.
The main reason for this is that GemFire itself has already created an initialized the Cache before
the Initializer gets invoked. As such, the Cache will already exist and since it is
a "Singleton", it cannot be re-initialized or have any of it's configuration augmented.
Spring Data GemFire already provides existing support for wiring GemFire components (such as CacheListeners,
CacheLoaders or CacheWriters) that are declared and created by GemFire in cache.xml
using the WiringDeclarableSupport
class as described in
Section 6.6.2, “Configuration using auto-wiring and annotations”.
However, this only works when Spring does the bootstrapping (i.e. bootstraps GemFire). When your Spring
application context is the one bootstrapped by GemFire, then these GemFire components go unnoticed since
the Spring application context does not even exist yet! The Spring application context will not get created
until GemFire calls the Initializer, which occurs after all the other GemFire components
and configuration have already been created and initialized.
So, in order to solve this problem, a new LazyWiringDeclarableSupport
class was
introduced, that is, in a sense, Spring application context aware. The intention of this abstract
base class is that any implementing class will register itself to be configured by the Spring
application context created by GemFire after the Initializer is called. In essence,
this give your GemFire managed component a chance to be configured and auto-wired with Spring beans defined
in the Spring application context.
In order for your GemFire application component to be auto-wired by the Spring container, create a
application class that extends the LazyWiringDeclarableSupport
and annotate
any class member that needs to be provided as a Spring bean dependency, similar to:
public static final class UserDataSourceCacheLoader extends LazyWiringDeclarableSupport implements CacheLoader<String, User> { @Autowired private DataSource userDataSource; ... }
As implied by the CacheLoader example above, you might necessarily (although, rare) have defined both
a Region and CacheListener component in GemFire cache.xml
. The CacheLoader may need
access to an application DAO, or perhaps Spring application context defined JDBC Data Source
for loading "Users" into a GemFire Cache REPLICATE
Region on start. Of course,
one should be careful in mixing the different life-cycles of GemFire and the Spring Container together
in this manner as not all use cases and scenarios are supported. The GemFire cache.xml
configuration would be similar to the following (which comes from SDG's test suite):
<?xml version="1.0"?> <!DOCTYPE cache PUBLIC "-//GemStone Systems, Inc.//GemFire Declarative Caching 7.0//EN" "http://www.gemstone.com/dtd/cache7_0.dtd"> <cache> <region name="Users" refid="REPLICATE"> <region-attributes initial-capacity="101" load-factor="0.85"> <key-constraint>java.lang.String</key-constraint> <value-constraint>org.springframework.data.gemfire.repository.sample.User</value-constraint> <cache-loader> <class-name>org.springframework.data.gemfire.support.SpringContextBootstrappingInitializerIntegrationTest$UserDataStoreCacheLoader</class-name> </cache-loader> </region-attributes> </region> <initializer> <class-name>org.springframework.data.gemfire.support.SpringContextBootstrappingInitializer</class-name> <parameter name="basePackages"> <string>org.springframework.data.gemfire.support.sample</string> </parameter> </initializer> </cache>
Note | |
---|---|
Sample applications are now maintained in the Spring Data GemFire Examples repository. |
The Spring Data GemFire project also includes one sample application. Named "Hello World", the sample demonstrates how to configure and use GemFire inside a Spring application. At runtime, the sample offers a shell to the user allowing him to run various commands against the grid. It provides an excellent starting point for users unfamiliar with the essential components or the Spring and GemFire concepts.
The sample is bundled with the distribution and is Maven-based. One can easily import them into any Maven-aware IDE (such as SpringSource Tool Suite) or run them from the command-line.
The Hello World sample demonstrates the core functionality of the Spring GemFire project. It bootstraps GemFire, configures it, executes arbitrary commands against it and shuts it down when the application exits. Multiple instances can be started at the same time as they will work with each other sharing data without any user intervention.
Running under Linux | |
---|---|
If you experience networking problems when starting GemFire or the
samples, try adding the following system property
|
Hello World is designed as a stand-alone java application. It
features a Main
class which can be started either
from your IDE of choice (in Eclipse/STS through Run As/Java
Application
) or from the command line through Maven using
mvn exec:java
. One can also use
java
directly on the resulting artifact if the
classpath is properly set.
To stop the sample, simply type exit
at the
command line or press Ctrl+C
to stop the VM and
shutdown the Spring container.
Once started, the sample will create a shared data grid and allow the user to issue commands against it. The output will likely look as follows:
INFO: Created GemFire Cache [Spring GemFire World] v. X.Y.Z INFO: Created new cache region [myWorld] INFO: Member xxxxxx:50694/51611 connecting to region [myWorld] Hello World! Want to interact with the world ? ... Supported commands are: get <key> - retrieves an entry (by key) from the grid put <key> <value> - puts a new entry into the grid remove <key> - removes an entry (by key) from the grid ...
For example to add new items to the grid one can use:
-> put 1 unu INFO: Added [1=unu] to the cache null -> put 1 one INFO: Updated [1] from [unu] to [one] unu -> size 1 -> put 2 two INFO: Added [2=two] to the cache null -> size 2
Multiple instances can be created at the same time. Once started, the new VMs automatically see the existing region and its information:
INFO: Connected to Distributed System ['Spring GemFire World'=xxxx:56218/49320@yyyyy] Hello World! ... -> size 2 -> map [2=two] [1=one] -> query length = 3 [one, two]
Experiment with the example, start (and stop) as many instances as you want, run various commands in one instance and see how the others react. To preserve data, at least one instance needs to be alive all times - if all instances are shutdown, the grid data is completely destroyed (in this example - to preserve data between runs, see the GemFire documentations).
Hello World uses both Spring XML and annotations for its
configuration. The initial boostrapping configuration is
app-context.xml
which includes the cache
configuration, defined under cache-context.xml
file
and performs classpath scanning
for Spring components.
The cache configuration defines the GemFire cache, region and for
illustrative purposes a simple cache listener that acts as a
logger.
The main beans are
HelloWorld
and CommandProcessor
which rely on the GemfireTemplate
to interact
with the distributed fabric. Both classes use annotations to define
their dependency and life-cycle callbacks.
In addition to this reference documentation, there are a number of other resources that may help you learn how to use GemFire and Spring framework. These additional, third-party resources are enumerated in this section.
Spring Data GemFire Core Schema (gfe)
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <xsd:schema xmlns="http://www.springframework.org/schema/gemfire" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:beans="http://www.springframework.org/schema/beans" xmlns:tool="http://www.springframework.org/schema/tool" xmlns:context="http://www.springframework.org/schema/context" xmlns:repository="http://www.springframework.org/schema/data/repository" targetNamespace="http://www.springframework.org/schema/gemfire" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.3"> <xsd:import namespace="http://www.springframework.org/schema/beans" /> <xsd:import namespace="http://www.springframework.org/schema/tool" /> <xsd:import namespace="http://www.springframework.org/schema/context" /> <!-- --> <xsd:annotation> <xsd:documentation><![CDATA[ Namespace support for the Spring GemFire project. ]]></xsd:documentation> </xsd:annotation> <!-- --> <xsd:complexType name="cacheBaseType"> <xsd:sequence> <xsd:element name="transaction-listener" type="beanDeclarationType" minOccurs="0" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation><![CDATA[ Registers a bean as a TransactionListener with the CacheTransactionManager. The bean must implement com.gemstone.gemfire.cache.TransactionListener and may be nested or referenced. ]]></xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="transaction-writer" type="beanDeclarationType" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation><![CDATA[ Registers a bean as a TransactionWriter with the CacheTransactionManager. The bean must implement com.gemstone.gemfire.cache.TransactionWriter and may be nested or referenced. ]]></xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="gateway-conflict-resolver" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.util.GatewayConflictResolver"><![CDATA[ A gateway conflict resolver for this cache. A gateway conflict resolver handles conflicts in the case of concurrent updates using a WAN gateway. The bean must implement com.gemstone.gemfire.cache.util.GatewayConflictResolver. Requires Gemfire version 7.0 or higher. ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.util.GatewayConflictResolver" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation><![CDATA[ Inner bean definition of the gateway conflict resolver. ]]></xsd:documentation> </xsd:annotation> </xsd:any> </xsd:sequence> <xsd:attribute name="ref" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the gateway conflict resolver bean referred by this declaration. Used as a convenience method. If no reference exists, use inner bean declarations. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> </xsd:element> <xsd:element name="dynamic-region-factory" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation><![CDATA[ Enables Dynamic Regions and specifies their configuration. ]]></xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:attribute name="disk-dir" type="xsd:string"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the directory path for disk persistence for dynamic regions. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="persistent" type="xsd:string" default="true"> <xsd:annotation> <xsd:documentation><![CDATA[ Enables persistence for dynamic regions. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="register-interest" type="xsd:string" default="true"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies whether dynamic regions register interest in all keys in a corresponding server region. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> </xsd:element> <xsd:element name="jndi-binding" type="jndiBindingType" minOccurs="0" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation><![CDATA[ Configures a data source to be bound to a JNDI context for use with Gemfire transactions ]]></xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> <xsd:attribute name="copy-on-read" type="xsd:string" use="optional" default="false"> <xsd:annotation> <xsd:documentation><![CDATA[ Controls whether entry value retrieval methods return direct references to the entry value objects in the cache (false) or copies of the objects (true). ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="id" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the cache definition (by default "gemfireCache").]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="cache-xml-location" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation source="org.springframework.core.io.Resource"><![CDATA[ The location of the GemFire cache xml file, as a Spring resource location: a URL, a "classpath:" pseudo URL, or a relative file path. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="properties-ref" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation source="java.util.Properties"><![CDATA[ The bean name of a Java Properties object that will be used for property substitution. For loading properties consider using a dedicated utility such as the <util:*/> namespace and its 'properties' element. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="use-bean-factory-locator" type="xsd:string" use="optional" default="true"> <xsd:annotation> <xsd:documentation><![CDATA[ Indicates whether a bean factory locator is enabled (default) for this cache definition or not. The locator stores the enclosing bean factory reference to allow auto-wiring of Spring beans into GemFire managed classes. Usually disabled when the same cache is used in multiple application context/bean factories inside the same VM. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="pdx-serializer-ref" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Sets the PDX serializer for the cache. If this serializer is set, it will be consulted to see if it can serialize any domain classes which are added to the cache in portable data exchange (PDX) format. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="pdx-disk-store" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Sets the name of the disk store to use for PDX meta data. When serializing objects in the PDX format, the type definitions are persisted to disk. This setting controls which disk store is used for that persistence. If not set, the metadata will go in the default disk store. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="pdx-persistent" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Control whether the type metadata for PDX objects is persisted to disk. Set to true if you are using persistent regions, WAN gateways or GemFire's JSON support. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="pdx-read-serialized" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Sets the object preference to PdxInstance type. When a cached object that was serialized as a PDX is read from the cache a PdxInstance will be returned instead of the actual domain class. The PdxInstance is an interface that provides run time access to the fields of a PDX without deserializing the entire PDX. The PdxInstance implementation is a light weight wrapper that simply refers to the raw bytes of the PDX that are kept in the cache. Using this method applications can choose to access PdxInstance instead of Java object. Note that a PdxInstance is only returned if a serialized PDX is found in the cache. If the cache contains a deserialized PDX, then a domain class instance is returned instead of a PdxInstance. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="pdx-ignore-unread-fields" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Controls whether pdx ignores fields that were unread during deserialization. The default is to preserve unread fields be including their data during serialization. But if you configure the cache to ignore unread fields then their data will be lost during serialization. You should only set this attribute to true if you know this member will only be reading cache data. In this use case you do not need to pay the cost of preserving the unread fields since you will never be reserializing pdx data. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="critical-heap-percentage"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.control.ResourceManager"><![CDATA[ Set the percentage of heap at or above which the cache is considered in danger of becoming inoperable due to garbage collection pauses or out of memory exceptions. Changing this value can cause a LowMemoryException to be thrown during certain cache operation. This feature requires additional VM flags to perform properly (see the JavaDocs for com.gemstone.gemfire.cache.control.ResourceManager for more information). ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="eviction-heap-percentage"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.control.ResourceManager"><![CDATA[ Set the percentage of heap at or above which the eviction should begin on Regions configured for HeapLRU eviction. This feature requires additional VM flags to perform properly (see the JavaDocs for com.gemstone.gemfire.cache.control.ResourceManager for more information). ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="close" default="true"> <xsd:annotation> <xsd:documentation><![CDATA[ Determines if the cache should be closed when the application context is closed. This value is true by default but should be set to false if deploying multiple applications in a jvm that share the same cache instance. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="lazy-init" default="true"> <xsd:annotation> <xsd:documentation><![CDATA[ Determines if the cache should be initialized automatically. Normally the cache will be lazily initialized, i.e., during creation of another bean references it. For cases in which there are no declared dependencies on the cache, set this attribute to false. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> <!-- --> <xsd:element name="cache"> <xsd:annotation> <xsd:documentation source="org.springframework.data.gemfire.CacheFactoryBean"><![CDATA[ Defines a GemFire Cache instance used for creating or retrieving 'regions'. ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.Cache" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:complexType> <xsd:complexContent> <xsd:extension base="cacheBaseType"> <xsd:attribute name="lock-timeout" type="xsd:string" use="optional" default="60"> <xsd:annotation> <xsd:documentation><![CDATA[ The timeout, in seconds, for implicit object lock requests. This setting affects automatic locking only, and does not apply to manual locking. If a lock request does not return before the specified timeout period, it is cancelled and returns with a failure. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="lock-lease" type="xsd:string" use="optional" default="120"> <xsd:annotation> <xsd:documentation><![CDATA[ The timeout, in seconds, for implicit and explicit object lock leases. This affects both automatic locking and manual locking. Once a lock is obtained, it can remain in force for the lock lease time period before being automatically cleared by the system ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="message-sync-interval" type="xsd:string" use="optional" default="1"> <xsd:annotation> <xsd:documentation><![CDATA[ Used for client subscription queue synchronization when this member acts as a server to clients and server redundancy is used. Sets the frequency (in seconds) at which the primary server sends messages to its secondary servers to remove queued events that have already been processed by the clients. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="search-timeout" type="xsd:string" use="optional" default="300"> <xsd:annotation> <xsd:documentation><![CDATA[ How many seconds a netSearch operation can wait for data before timing out. You may want to change this based on your knowledge of the network load or other factors. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> <!-- --> <xsd:element name="client-cache"> <xsd:annotation> <xsd:documentation source="org.springframework.data.gemfire.client.ClientCacheFactoryBean"><![CDATA[ Defines a GemFire Client Cache instance used for creating or retrieving 'regions'. ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.client.ClientCache" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:complexType> <xsd:complexContent> <xsd:extension base="cacheBaseType"> <xsd:attribute name="pool-name" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the pool used by this client. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="ready-for-events" type="xsd:string" use="optional" default="false"> <xsd:annotation> <xsd:documentation><![CDATA[ Notifies the server that this durable client is ready to receive updates. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> <!-- --> <xsd:element name="transaction-manager"> <xsd:annotation> <xsd:documentation source="org.springframework.data.gemfire.GemfireTransactionManager"><![CDATA[ Defines a GemFire Transaction Manager instance for a single GemFire cache. ]]></xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:attribute name="id" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the transaction manager definition (by default "gemfireTransactionManager").]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="cache-ref" type="xsd:string" use="optional" default="gemfireCache"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the bean defining the GemFire cache (by default 'gemfireCache'). ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="copy-on-read" type="xsd:string" use="optional" default="true"> <xsd:annotation> <xsd:documentation><![CDATA[ Indicates whether the cache returns direct references or copies of the objects (default) it manages. While copies imply additional work for every fetch operation, direct references can cause dirty reads across concurrent threads in the same VM, whether or not transactions are used. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> </xsd:element> <!-- nested bean definition --> <xsd:complexType name="beanDeclarationType"> <xsd:sequence> <xsd:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation><![CDATA[ Inner bean definition. The nested declaration serves as an alternative to bean references (using both in the same definition) is illegal. ]]></xsd:documentation> </xsd:annotation> </xsd:any> </xsd:sequence> <xsd:attribute name="ref" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the bean referred by this declaration. If no reference exists, use an inner bean declaration. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> <!-- --> <xsd:complexType name="baseLookupRegionType"> <xsd:annotation> <xsd:documentation><![CDATA[ Defines a lookup Subregion ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.Region" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:complexContent> <xsd:extension base="basicRegionType"> <xsd:group ref="subRegionGroup" minOccurs="0" maxOccurs="unbounded" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="basicSubRegionType"> <xsd:complexContent> <xsd:extension base="baseLookupRegionType"> <xsd:attribute name="name" type="xsd:string"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the region definition.]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="basicRegionType"> <xsd:annotation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.Region" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> </xsd:complexType> <!-- --> <xsd:complexType name="baseReadOnlyRegionType" abstract="true"> <xsd:complexContent> <xsd:extension base="basicRegionType"> <xsd:sequence> <xsd:element name="cache-listener" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.CacheListener"><![CDATA[ A cache listener definition for this region. A cache listener handles region or entry related events (that occur after various operations on the region). Multiple listeners can be declared in a nested manner. Note: Avoid the risk of deadlock. Since the listener is invoked while holding a lock on the entry generating the event, it is easy to generate a deadlock by interacting with the region. For this reason, it is highly recommended to use some other thread for accessing the region and not waiting for it to complete its task. ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.CacheListener" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation><![CDATA[ Inner bean definition of the cache listener. ]]></xsd:documentation> </xsd:annotation> </xsd:any> </xsd:sequence> <xsd:attribute name="ref" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the cache listener bean referred by this declaration. Used as a convenience method. If no reference exists, use inner bean declarations. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> </xsd:element> <xsd:element name="region-ttl" type="expirationType" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation><![CDATA[[ Time to live configuration for the region itself. Default: no expiration. ]]></xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="region-tti" type="expirationType" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation><![CDATA[[ Time to idle (or idle timeout) configuration for the region itself. Default: no expiration. ]]></xsd:documentation> </xsd:annotation> </xsd:element> <xsd:choice> <xsd:element name="entry-ttl" type="expirationType" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation><![CDATA[[ Time to live configuration for the region entries. Default: no expiration. ]]></xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="custom-entry-ttl" type="customExpirationType" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.CustomExpiry" /> </tool:annotation> </xsd:appinfo> <xsd:documentation><![CDATA[[ CustomExpiry time to live configuration for the region entries. Default: no expiration. ]]></xsd:documentation> </xsd:annotation> </xsd:element> </xsd:choice> <xsd:choice> <xsd:element name="entry-tti" type="expirationType" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation><![CDATA[[ Time to idle (or idle timeout) configuration for the region entries. Default: no expiration. ]]></xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="custom-entry-tti" type="customExpirationType" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.CustomExpiry" /> </tool:annotation> </xsd:appinfo> <xsd:documentation><![CDATA[[ CustomExpiry Time to idle (or idle timeout) configuration for the region entries. Default: no expiration. ]]></xsd:documentation> </xsd:annotation> </xsd:element> </xsd:choice> </xsd:sequence> <xsd:attribute name="persistent" type="xsd:string"> <xsd:annotation> <xsd:documentation><![CDATA[ Indicates whether the defined region is persistent. 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. Default is false, meaning the regions are not persisted. Note: Persistence for partitioned regions is supported only from GemFire 6.5 onwards. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="disk-synchronous" type="xsd:string" default="false"> <xsd:annotation> <xsd:documentation><![CDATA[ Indicates whether the writing to the disk is synchronous or not. Default is false, meaning asynchronous writing. Note this attribute only applies if a disk store is configured for this region. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="disk-store-ref" type="xsd:string"> <xsd:annotation> <xsd:documentation><![CDATA[ Indicates the id of the disk store to use for persistence or overflow. Note this attribute only applies if a disk store is configured for this region. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="load-factor" type="xsd:string" default="0.75"> <xsd:annotation> <xsd:documentation><![CDATA[[ Together with the initial-capacity region attribute, sets the initial parameters on the underlying java.util.ConcurrentHashMap used for storing region entries. This must be a floating point number between 0 and 1, inclusive. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="cloning-enabled" type="xsd:string" default="true"> <xsd:annotation> <xsd:documentation><![CDATA[[ Determines how fromDelta applies deltas to the local cache for delta propagation. When true, the updates are applied to a clone of the value and then the clone is saved to the cache. When false, the value is modified in place in the cache. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="concurrency-checks-enabled" type="xsd:string" default="true"> <xsd:annotation> <xsd:documentation><![CDATA[[ Indicates whether concurrency checks (versioning) are enabled for the region ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="destroy" type="xsd:string" default="false"> <xsd:annotation> <xsd:documentation><![CDATA[ Indicates whether the defined region should be destroyed or not at shutdown. Destroy cascades to all entries and subregions. After the destroy, this region object can not be used any more and any attempt to use this region object will get RegionDestroyedException. Default is false, meaning that regions are not destroyed. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="close" type="xsd:string" default="false"> <xsd:annotation> <xsd:documentation><![CDATA[ Indicates whether the defined region should be closed or not at shutdown. Close performs a local destroy but leaves behind the region disk files. Additionally it notifies the listeners and callbacks. Default is false Note: Regions are automatically closed when cache closes. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="statistics" type="xsd:string" default="false"> <xsd:annotation> <xsd:documentation><![CDATA[ Indicates whether statistics are enabled or disabled for this region and its entries. Default is false, meaning statistics are disabled. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="key-constraint" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The fully qualified class name of the expected key type ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="value-constraint" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The fully qualified class name of the expected value type ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="ignore-jta" type="xsd:string" use="optional" default="false"> <xsd:annotation> <xsd:documentation><![CDATA[ Indicates whether operations on this region participates in active JTA transactions or ignores them and operates outside of transactions. This is primarily used in cache loaders, writers, and listeners that need to perform non-transactional operations on a region, such as caching a result set. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="initial-capacity" type="xsd:string" use="optional" default="16"> <xsd:annotation> <xsd:documentation><![CDATA[ Sets the initial capacity (number of entries) for the region ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> <!-- --> <xsd:complexType name="readOnlyRegionType"> <xsd:complexContent> <xsd:extension base="baseReadOnlyRegionType"> <xsd:attributeGroup ref="topLevelRegionAttributes" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <!-- --> <xsd:complexType name="readOnlySubRegionType"> <xsd:complexContent> <xsd:extension base="baseReadOnlyRegionType"> <xsd:attribute name="name" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the region definition.]]> </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> <!-- --> <xsd:complexType name="baseRegionType"> <xsd:complexContent> <xsd:extension base="baseReadOnlyRegionType"> <xsd:sequence minOccurs="0" maxOccurs="1"> <xsd:element name="cache-loader" type="beanDeclarationType" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.CacheLoader"><![CDATA[ The cache loader definition for this region. A cache loader allows data to be placed into a region. ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.CacheLoader" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> </xsd:element> <xsd:element name="cache-writer" type="beanDeclarationType" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.CacheWriter"><![CDATA[ The cache writer definition for this region. A cache writer acts as a dedicated synchronous listener that is notified before a region or an entry is modified. A typical example would be a writer that updates the database. Note: Only one CacheWriter is invoked. GemFire will always prefer the local one (if it exists) otherwise it will arbitrarily pick one. ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.CacheWriter" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> </xsd:element> <xsd:element name="membership-attributes" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation><![CDATA[ Configures a Region to require one or more membership roles to be present in the system for reliable access to the Region ]]></xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:attribute name="required-roles" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ A comma delimited list of required role names ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="loss-action" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the behavior when one or more required roles are missing: (full-access, limited-access, no-access, or reconnect) ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="resumption-action" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies how the region is affected by resumption of reliability when one or more missing required roles is restored to the distributed membership (none or reinitialize) ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> </xsd:element> <xsd:choice minOccurs="0" maxOccurs="unbounded"> <xsd:element name="gateway-sender" type="baseGatewaySenderType" /> <xsd:element name="gateway-sender-ref"> <xsd:complexType> <xsd:attribute name="bean" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the gateway sender bean referred by this declaration. Used as a convenience method. If no reference exists, use inner bean declarations. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> </xsd:element> </xsd:choice> <xsd:choice minOccurs="0" maxOccurs="unbounded"> <xsd:element name="async-event-queue" type="baseAsyncEventQueueType" /> <xsd:element name="async-event-queue-ref"> <xsd:complexType> <xsd:attribute name="bean" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the gateway sender bean referred by this declaration. Used as a convenience method. If no reference exists, use inner bean declarations. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> </xsd:element> </xsd:choice> </xsd:sequence> <xsd:attribute name="index-update-type" use="optional" default="synchronous"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies whether region indexes are maintained synchronously with region modifications, or asynchronously in a background thread. ]]></xsd:documentation> </xsd:annotation> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="asynchronous" /> <xsd:enumeration value="synchronous" /> </xsd:restriction> </xsd:simpleType> </xsd:attribute> <xsd:attribute name="enable-gateway" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies if WAN gateway communications are enabled for this region (true or false) (Deprecated since Gemfire v 7.0) ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="hub-id" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies if WAN gateway hub id if enable-gateway is true. (Deprecated since Gemfire v 7.0) ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> <!-- --> <xsd:complexType name="regionType"> <xsd:complexContent> <xsd:extension base="baseRegionType"> <xsd:attributeGroup ref="topLevelRegionAttributes" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:complexType name="subRegionType"> <xsd:complexContent> <xsd:extension base="baseRegionType"> <xsd:attribute name="name" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the region definition. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> <!-- --> <xsd:complexType name="lookupRegionType"> <xsd:complexContent> <xsd:extension base="baseLookupRegionType"> <xsd:attributeGroup ref="topLevelRegionAttributes" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <!-- --> <xsd:complexType name="lookupSubRegionType"> <xsd:complexContent> <xsd:extension base="baseLookupRegionType"> <xsd:attribute name="name" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the region definition. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> <!-- --> <xsd:group name="subRegionGroup"> <xsd:choice> <xsd:element name="lookup-region" type="lookupSubRegionType" /> <xsd:element name="replicated-region" type="replicatedSubRegionType" /> <xsd:element name="partitioned-region" type="partitionedSubRegionType" /> <xsd:element name="local-region" type="localSubRegionType" /> </xsd:choice> </xsd:group> <!-- --> <xsd:attributeGroup name="topLevelRegionAttributes"> <xsd:attribute name="id" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ The id of the region bean definition. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="cache-ref" type="xsd:string" use="optional" default="gemfireCache"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the bean defining the GemFire cache (by default 'gemfireCache'). ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="name" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the region definition. If no specified, it will have the value of the id attribute (that is, the bean name). Required for subregions. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:attributeGroup> <!-- --> <xsd:attributeGroup name="distributedRegionAttributes"> <xsd:attribute name="enable-subscription-conflation" type="xsd:string" default="false"> <xsd:annotation> <xsd:documentation><![CDATA[ Indicates whether the region can conflate its messages to the client. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="enable-async-conflation" type="xsd:string" default="false"> <xsd:annotation> <xsd:documentation><![CDATA[ For TCP/IP distributions between peers, specifies whether to allow aggregation of asynchronous messages sent by the producer member for the region. This is a special-purpose boolean attribute that applies only when asynchronous queues are used for slow consumers ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="multicast-enabled" type="xsd:string"> <xsd:annotation> <xsd:documentation><![CDATA[ Boolean that indicates whether distributed operations on a region should use multicasting. To enable this, multicast must be enabled for the distributed system with the mcast-port gemfire.properties setting. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:attributeGroup> <!-- --> <xsd:element name="lookup-region" type="lookupRegionType" /> <!-- --> <xsd:complexType name="baseReplicatedRegionType"> <xsd:annotation> <xsd:documentation source="org.springframework.data.gemfire.RegionFactoryBean"><![CDATA[ Defines a GemFire replicated region instance. Each replicated region contains a complete copy of the data. As well as high availability, replication provides excellent performance as each region contains a complete, up to date copy of the data. ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.Region" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:complexContent> <xsd:extension base="baseRegionType"> <xsd:sequence> <xsd:element name="subscription" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation><![CDATA[ Subscription policy for the replicated region. ]]></xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:attribute name="type" type="subscriptionPolicyType" /> </xsd:complexType> </xsd:element> <xsd:element name="eviction" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation><![CDATA[ Eviction policy for the replicated region. ]]></xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:complexContent> <xsd:extension base="evictionType"> <xsd:attribute name="action" type="evictionActionType" fixed="OVERFLOW_TO_DISK"> <xsd:annotation> <xsd:documentation><![CDATA[ The action to take when performing eviction. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> <xsd:group ref="subRegionGroup" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> <xsd:attributeGroup ref="distributedRegionAttributes" /> <xsd:attribute name="concurrency-level"> <xsd:annotation> <xsd:documentation><![CDATA[ Provides an estimate of the maximum number of application threads that will concurrently access a region entry at one time. This attribute does not apply to partitioned regions. This attribute helps GemFire optimize the use of system resources and reduce thread contention. This sets an initial parameter on the underlying java.util.ConcurrentHashMap used for storing region entries. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="scope" type="xsd:string"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the scope for this region: distributed-ack,distributed-no-ack, global ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="data-policy" type="xsd:string"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the data policy for this region ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="is-lock-grantor" type="xsd:string" use="optional" default="false"> <xsd:annotation> <xsd:documentation><![CDATA[ Indicates whether the region is a lock grantor.This attribute is only relevant for regions with global scope, as only they allow locking. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> <!-- --> <xsd:complexType name="replicatedRegionType"> <xsd:complexContent> <xsd:extension base="baseReplicatedRegionType"> <xsd:attributeGroup ref="topLevelRegionAttributes" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <!-- --> <xsd:complexType name="replicatedSubRegionType"> <xsd:complexContent> <xsd:extension base="baseReplicatedRegionType"> <xsd:attribute name="name" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the region definition. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> <!-- --> <xsd:element name="replicated-region" type="replicatedRegionType" /> <!-- --> <xsd:complexType name="baseLocalRegionType"> <xsd:annotation> <xsd:documentation source="org.springframework.data.gemfire.ReplicatedRegionFactoryBean"><![CDATA[ Defines a GemFire local region instance. Each local region is scoped only to the local JVM. ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.Region" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:complexContent> <xsd:extension base="baseRegionType"> <xsd:sequence minOccurs="1" maxOccurs="1"> <xsd:element name="eviction" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation><![CDATA[ Eviction policy for the replicated region. ]]></xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:complexContent> <xsd:extension base="evictionType"> <xsd:attribute name="action" type="evictionActionType" fixed="OVERFLOW_TO_DISK"> <xsd:annotation> <xsd:documentation><![CDATA[ The action to take when performing eviction. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> <xsd:group ref="subRegionGroup" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> <xsd:attribute name="data-policy" type="xsd:string"> <xsd:annotation> <xsd:documentation><![CDATA[ Indicates the DataPolicy to use for this region (NORMAL or PRELOADED) ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="concurrency-level"> <xsd:annotation> <xsd:documentation><![CDATA[ Provides an estimate of the maximum number of application threads that will concurrently access a region entry at one time. This attribute does not apply to partitioned regions. This attribute helps GemFire optimize the use of system resources and reduce thread contention. This sets an initial parameter on the underlying java.util.ConcurrentHashMap used for storing region entries. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> <!-- --> <xsd:complexType name="localRegionType"> <xsd:complexContent> <xsd:extension base="baseLocalRegionType"> <xsd:attributeGroup ref="topLevelRegionAttributes" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> <!-- --> <xsd:complexType name="localSubRegionType"> <xsd:complexContent> <xsd:extension base="baseLocalRegionType"> <xsd:attribute name="name" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the region definition. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> <!-- --> <xsd:element name="local-region" type="localRegionType" /> <!-- --> <xsd:complexType name="basePartitionedRegionType"> <xsd:annotation> <xsd:documentation source="org.springframework.data.gemfire.RegionFactoryBean"><![CDATA[ Defines a GemFire partitioned region instance. Through partitioning, the data is split across regions. Partitioning is useful when the amount of data to store is too large for one member to hold and work with as if it were a single entity. One can configure the partitioned region to store redundant copies in different members, for high availability in case of an application failure. ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.Region" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:complexContent> <xsd:extension base="baseRegionType"> <xsd:sequence> <xsd:element name="partition-resolver" type="beanDeclarationType" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.PartitionResolver"><![CDATA[ The partition resolver definition for this region, allowing for custom partitioning. GemFire uses the resolver to colocate data based on custom criterias (such as colocating trades by month and year). ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.PartitionResolver" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> </xsd:element> <xsd:element name="partition-listener" type="beanDeclarationType" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.partition.PartitionListener"><![CDATA[ The partition listener definition for this region. Defines a callback for partitioned regions, invoked when a partition region is created or any bucket in a partitioned region becomes primary ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.partition.PartitionListener" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> </xsd:element> <xsd:element name="fixed-partition" minOccurs="0" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.partition.FixedPartitionAttributes"><![CDATA[ Create a fixed partition with the given attributes. Required for a FixedPartitionResolver. ]]></xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:attribute name="partition-name" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.partition.FixedPartitionAttributes"><![CDATA[ Specifies the fixed partition name ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="primary" use="optional" default="true"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.partition.FixedPartitionAttributes"><![CDATA[ Specifies if this member is primary for this partition ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="num-buckets" use="optional"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.partition.FixedPartitionAttributes"><![CDATA[ Specifies the number of buckets to allocate to the fixed partition ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> </xsd:element> <xsd:element name="subscription" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation><![CDATA[ Subscription policy for the partitioned region. ]]></xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:attribute name="type" type="subscriptionPolicyType" /> </xsd:complexType> </xsd:element> <xsd:element name="eviction" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation><![CDATA[ Eviction policy for the partitioned region. ]]></xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:complexContent> <xsd:extension base="evictionType"> <xsd:attribute name="action" type="evictionActionType" default="LOCAL_DESTROY"> <xsd:annotation> <xsd:documentation><![CDATA[ The action to take when performing eviction. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> </xsd:sequence> <xsd:attributeGroup ref="distributedRegionAttributes" /> <xsd:attribute name="copies" use="optional" default="0" type="xsd:string"> <xsd:annotation> <xsd:documentation><![CDATA[ The number of copies (0-3) for each partition for high-availability. By default, no copies are created meaning there is no redundancy. Each copy provides extra backup at the expense of extra storages. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="colocated-with" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the partitioned region with which this newly created partitioned region is colocated. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="local-max-memory" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The maximum amount of memory, in megabytes, to be used by the region in this process. If not set, a default of 90% of available heap is used. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="total-max-memory" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The maximum amount of memory, in megabytes, to be used by the region in all process. Note: This setting must be the same in all processes using the region. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="total-buckets" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The total number of hash buckets to be used by the region in all processes. A bucket is the smallest unit of data management in a partitioned region. Entries are stored in buckets and buckets may move from one VM to another. Buckets may also have copies, depending on redundancy to provide high availability in the face of VM failure. The number of buckets should be prime and as a rough guide at the least four times the number of partition VMs. However , there is significant overhead to managing a bucket, particularly for higher values of redundancy. Note: This setting must be the same in all processes using the region. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="recovery-delay" type="xsd:string" use="optional" default="-1"> <xsd:annotation> <xsd:documentation><![CDATA[ The delay in milliseconds that existing members will wait before satisfying redundancy after another member crashes. -1 (the default) indicates that redundancy will not be recovered after a failure. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="startup-recovery-delay" type="xsd:string" use="optional" default="-1"> <xsd:annotation> <xsd:documentation><![CDATA[ The delay in milliseconds that new members will wait before satisfying redundancy. -1 indicates that adding new members will not trigger redundancy recovery. The default is to recover redundancy immediately when a new member is added. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> <!-- --> <xsd:complexType name="partitionedRegionType"> <xsd:complexContent> <xsd:extension base="basePartitionedRegionType"> <xsd:attributeGroup ref="topLevelRegionAttributes" /> </xsd:extension> <!-- subRegions not supported --> </xsd:complexContent> </xsd:complexType> <!-- --> <xsd:complexType name="partitionedSubRegionType"> <xsd:complexContent> <xsd:extension base="basePartitionedRegionType"> <xsd:attribute name="name" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the region definition. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> <!-- subRegions not supported --> </xsd:complexContent> </xsd:complexType> <!-- --> <xsd:element name="partitioned-region" type="partitionedRegionType" /> <!-- --> <xsd:complexType name="expirationType"> <xsd:attribute name="timeout" type="xsd:string" default="0"> <xsd:annotation> <xsd:documentation><![CDATA[ The amount of time before the expiration action takes place. Defaults to zero (which means never timeout). ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="action" default="INVALIDATE"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="INVALIDATE"> <xsd:annotation> <xsd:documentation><![CDATA[ When the region or cached object expires, it is invalidated. ]]></xsd:documentation> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="DESTROY"> <xsd:annotation> <xsd:documentation><![CDATA[ When the region or cached object expires, it is destroyed. ]]></xsd:documentation> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="LOCAL_INVALIDATE"> <xsd:annotation> <xsd:documentation><![CDATA[ When the region or cached object expires, it is invalidated locally only. Not supported on partitioned regions. ]]></xsd:documentation> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="LOCAL_DESTROY"> <xsd:annotation> <xsd:documentation><![CDATA[ When the region or cached object expires, it is destroyed locally only. Not supported on partitioned regions. ]]></xsd:documentation> </xsd:annotation> </xsd:enumeration> </xsd:restriction> </xsd:simpleType> </xsd:attribute> </xsd:complexType> <!-- --> <xsd:complexType name="customExpirationType"> <xsd:sequence> <xsd:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation><![CDATA[ Inner bean definition of the CustomExpiry. ]]></xsd:documentation> </xsd:annotation> </xsd:any> </xsd:sequence> <xsd:attribute name="ref" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the CustomExpiry bean referred by this declaration. Used as a convenience method. If no reference exists, use inner bean declarations. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> <!-- --> <xsd:complexType name="evictionType"> <xsd:sequence minOccurs="0" maxOccurs="1"> <xsd:element name="object-sizer" type="beanDeclarationType"> <xsd:annotation> <xsd:documentation><![CDATA[ Entity computing sizes for objects stored into the grid. ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.util.ObjectSizer" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> </xsd:element> </xsd:sequence> <xsd:attribute name="type" default="ENTRY_COUNT"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="ENTRY_COUNT"> <xsd:annotation> <xsd:documentation><![CDATA[ Considers the number of entries in the region before performing an eviction. ]]></xsd:documentation> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="MEMORY_SIZE"> <xsd:annotation> <xsd:documentation><![CDATA[ Considers the amount of memory consumed by the region before performing an eviction. ]]></xsd:documentation> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="HEAP_PERCENTAGE"> <xsd:annotation> <xsd:documentation><![CDATA[ Considers the amount of heap used (through the GemFire resource manager) before performing an eviction. ]]></xsd:documentation> </xsd:annotation> </xsd:enumeration> </xsd:restriction> </xsd:simpleType> </xsd:attribute> <xsd:attribute name="threshold" type="xsd:string"> <xsd:annotation> <xsd:documentation><![CDATA[ The threshold (or limit) against which the eviction algorithm runs. Once the threashold is reached, eviction is performed. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> <!-- --> <xsd:simpleType name="evictionActionType"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="LOCAL_DESTROY"> <xsd:annotation> <xsd:documentation><![CDATA[ The LRU (least-recently-used) region entries is locally destroyed. Note: this option is not compatible with replicated regions (as it render the replica region incomplete). ]]></xsd:documentation> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="OVERFLOW_TO_DISK"> <xsd:annotation> <xsd:documentation><![CDATA[ The LRU (least-recently-used) region entry values are written to disk and nulled-out in the member to reclaim memory. ]]></xsd:documentation> </xsd:annotation> </xsd:enumeration> </xsd:restriction> </xsd:simpleType> <xsd:simpleType name="subscriptionPolicyType"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="ALL"> <xsd:annotation> <xsd:documentation><![CDATA[ This subscriber is interested in all data. More specifically operations done in this cache and distributed operations done in remote caches. When combined with DataPolicy.EMPTY this region will receive events for every distributed operation but will not store the data. When combined with DataPolicy.NORMAL or DataPolicy.PRELOADED this region will accept Region.create(Object, Object) operations done remotely. Without the ALL interest policy, NORMAL and PRELOADED ignore creates that the region does not have an existing entry for. When combined with the replication policies this interest has no effect. When combined with DataPolicy.PARTITION this interest policy causes cache listeners to be notified of changes regardless of the physical location of the data affected. That is, a listener in a VM using this policy will receive notification of all changes to the partitioned region. ]]></xsd:documentation> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="CACHE_CONTENT"> <xsd:annotation> <xsd:documentation><![CDATA[ This subscriber is interested in data that is already in its cache. More specifically operations done in this cache and distributed operations done in remote caches. When combined with DataPolicy.EMPTY this region will never receive events for distributed operations since its content is always empty. It will continue to get events for operations done locally. When combined with DataPolicy.NORMAL or DataPolicy.PRELOADED this region will accept remote operations done to entries it already has in its cache. When combined with the replication policies * this interest has no effect. When combined with DataPolicy.PARTITION this interest policy causes cache listeners to be notified in the VM holding the affected data. That is, listeners are only notified if the affected* key-value pair is in the same process as the listener. ]]></xsd:documentation> </xsd:annotation> </xsd:enumeration> </xsd:restriction> </xsd:simpleType> <!-- --> <xsd:complexType name="baseDiskStoreType"> <xsd:sequence> <xsd:element name="disk-dir" minOccurs="0" maxOccurs="unbounded"> <xsd:complexType> <xsd:attribute name="location" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ Directory on the file system for storing data. Note: the directory must already exist. ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.DiskStore" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> </xsd:attribute> <xsd:attribute name="max-size" type="xsd:string" default="2147483647"> <xsd:annotation> <xsd:documentation><![CDATA[ The maximum size (in megabytes) of data stored in each directory. Default value is 2,147,483,647 which is two petabytes. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> </xsd:element> </xsd:sequence> <xsd:attribute name="auto-compact" type="xsd:string" default="true"> <xsd:annotation> <xsd:documentation><![CDATA[ Indicates whether or not the operation logs are automatically compacted or not. Default is true. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="max-oplog-size" type="xsd:string" default="1024"> <xsd:annotation> <xsd:documentation><![CDATA[ Sets the maximum size in megabytes a single oplog (operation log) is allowed to be. When an oplog is created this amount of file space will be immediately reserved. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="time-interval" type="xsd:string" default="1000"> <xsd:annotation> <xsd:documentation><![CDATA[ Sets the number of milliseconds that can elapse before unwritten data is written to disk. It is considered only for asynchronous writing. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="queue-size" type="xsd:string" default="0"> <xsd:annotation> <xsd:documentation><![CDATA[ The maximum number of operations that can be asynchronously queued. Once this many pending async operations have been queued async ops will begin blocking until some of the queued ops have been flushed to disk. Considered only for asynchronous writing. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="compaction-threshold" type="xsd:string" default="50"> <xsd:annotation> <xsd:documentation><![CDATA[ Sets the threshold at which an oplog will become compactable. Until it reaches this threshold the oplog will not be compacted. The threshold is a percentage in the range 0..100. When the amount of garbage in an oplog exceeds this percentage then when a compaction is done and this garbage will be cleaned up freeing up disk space. Garbage is created by entry destroys, entry updates, and region destroys. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="allow-force-compaction" type="xsd:string" default="false"> <xsd:annotation> <xsd:documentation><![CDATA[ Indicates whether forced compaction is allowed for regions using this disk store ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="write-buffer-size" type="xsd:string" default="32768"> <xsd:annotation> <xsd:documentation><![CDATA[ Indicates the write buffer size in bytes ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> <!-- --> <xsd:complexType name="diskStoreType"> <xsd:complexContent> <xsd:extension base="baseDiskStoreType"> <xsd:attribute name="id" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the disk store bean definition. This is also used as the disk store name]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="cache-ref" type="xsd:string" use="optional" default="gemfireCache"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the bean defining the GemFire cache (by default 'gemfireCache'). ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> <!-- --> <xsd:element name="disk-store" type="diskStoreType" /> <!-- --> <xsd:element name="client-region"> <xsd:annotation> <xsd:documentation source="org.springframework.data.gemfire.client.ClientRegionFactoryBean"><![CDATA[ Defines a GemFire client region instance. A client region is connected to a (long-lived) farm of GemFire servers from which it receives its data. The client can hold some data locally or forward all requests to the server. ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.Region" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:complexType> <xsd:complexContent> <xsd:extension base="readOnlyRegionType"> <xsd:sequence> <xsd:element name="cache-loader" type="beanDeclarationType" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.CacheLoader"><![CDATA[ The cache loader definition for this region. A cache loader allows data to be placed into a region. ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.CacheLoader" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> </xsd:element> <xsd:element name="cache-writer" type="beanDeclarationType" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.CacheWriter"><![CDATA[ The cache writer definition for this region. A cache writer acts as a dedicated synchronous listener that is notified before a region or an entry is modified. A typical example would be a writer that updates the database. Note: Only one CacheWriter is invoked. GemFire will always prefer the local one (if it exists) otherwise it will arbitrarily pick one. ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.CacheWriter" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> </xsd:element> <xsd:choice minOccurs="0" maxOccurs="unbounded"> <xsd:element name="key-interest"> <xsd:annotation> <xsd:documentation><![CDATA[ Key based interest. If the key is a List, then all the keys in the List will be registered. The key can also be the special token 'ALL_KEYS', which will register interest in all keys in the region. In effect, this will cause an update to any key in this region in the CacheServer to be pushed to the client. ]]></xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:complexContent> <xsd:extension base="interestType"> <xsd:sequence minOccurs="0" maxOccurs="1"> <xsd:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation><![CDATA[ Inner bean definition of the client key interest. ]]></xsd:documentation> </xsd:annotation> </xsd:any> </xsd:sequence> <xsd:attribute name="key-ref" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the client key interest bean referred by this declaration. Used as a convenience method. If no reference exists, use the inner bean declaration. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> <xsd:element name="regex-interest"> <xsd:annotation> <xsd:documentation><![CDATA[ Regular expression based interest. If the pattern is '.*' then all keys of any type will be pushed to the client. ]]></xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:complexContent> <xsd:extension base="interestType"> <xsd:attribute name="pattern" type="xsd:string" /> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> </xsd:choice> <xsd:element name="eviction" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation><![CDATA[ Eviction policy for the partitioned region. ]]></xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:complexContent> <xsd:extension base="evictionType"> <xsd:attribute name="action" type="evictionActionType" default="LOCAL_DESTROY"> <xsd:annotation> <xsd:documentation><![CDATA[ The action to take when performing eviction. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> </xsd:sequence> <xsd:attribute name="data-policy" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The data policy for this client. Can be either 'EMPTY' or 'NORMAL' (the default). In case persistence or overflow are configured for this region, this parameter will be ignored. EMPTY - causes data to never be stored in local memory. The region will always appear empty. It can be used to for zero footprint producers that only want to distribute their data to others and for zero footprint consumers that only want to see events. NORMAL - causes data that this region is interested in to be stored in local memory. It allows the contents in this cache to differ from other caches. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="pool-name" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the pool used by this client. If not set, a default pool (initialized when using client-cache) will be used. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="shortcut" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The ClientRegionShortcut for this region. Allows easy initialization of the region based on defaults. ]]></xsd:documentation> </xsd:annotation> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="PROXY" /> <xsd:enumeration value="CACHING_PROXY" /> <xsd:enumeration value="CACHING_PROXY_HEAP_LRU" /> <xsd:enumeration value="CACHING_PROXY_OVERFLOW" /> <xsd:enumeration value="LOCAL" /> <xsd:enumeration value="LOCAL_PERSISTENT" /> <xsd:enumeration value="LOCAL_HEAP_LRU" /> <xsd:enumeration value="LOCAL_OVERFLOW" /> <xsd:enumeration value="LOCAL_PERSISTENT_OVERFLOW" /> </xsd:restriction> </xsd:simpleType> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> <!-- --> <xsd:complexType name="connectionType"> <xsd:attribute name="host" type="xsd:string"> <xsd:annotation> <xsd:documentation><![CDATA[ The host name or ip address of the connection. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="port"> <xsd:annotation> <xsd:documentation><![CDATA[ The port number of the connection (between 1 and 65535 inclusive). ]]></xsd:documentation> </xsd:annotation> <xsd:simpleType> <xsd:restriction base="xsd:string" /> </xsd:simpleType> </xsd:attribute> </xsd:complexType> <!-- --> <xsd:complexType name="interestType" abstract="true"> <xsd:attribute name="durable" type="xsd:string" use="optional" default="false"> <xsd:annotation> <xsd:documentation><![CDATA[ Indicates whether or not the registered interest is durable or not. Default is false. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="result-policy" use="optional" default="KEYS_VALUES"> <xsd:annotation> <xsd:documentation><![CDATA[ The result policy for this interest. Can be one of 'KEYS' or 'KEYS_VALUES' (the default) or 'NONE'. KEYS - Initializes the local cache with the keys satisfying the request. KEYS-VALUES - initializes the local cache with the keys and current values satisfying the request. NONE - Does not initialize the local cache. ]]></xsd:documentation> </xsd:annotation> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="KEYS" /> <xsd:enumeration value="KEYS_VALUES" /> <xsd:enumeration value="NONE" /> </xsd:restriction> </xsd:simpleType> </xsd:attribute> <xsd:attribute name="receive-values" type="xsd:string" use="optional" default="true"> <xsd:annotation> <xsd:documentation><![CDATA[ Indicates whether values are received with create and update events on keys of interest (true) or only invalidations are received and the value will be received on the next get instead (false). Default is true. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> <!-- --> <xsd:element name="pool"> <xsd:annotation> <xsd:documentation source="org.springframework.data.gemfire.client.PoolFactoryBean"><![CDATA[ Defines a pool for connections from a client to a set of GemFire Cache Servers. Note that in order to instantiate a pool, a GemFire cache needs to be already started. ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.client.Pool" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:complexType> <xsd:choice minOccurs="1" maxOccurs="1"> <xsd:element name="locator" type="connectionType" minOccurs="1" maxOccurs="unbounded" /> <xsd:element name="server" type="connectionType" minOccurs="1" maxOccurs="unbounded" /> </xsd:choice> <xsd:attribute name="id" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the pool definition (by default "gemfirePool").]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="free-connection-timeout" type="xsd:string" use="optional" /> <xsd:attribute name="idle-timeout" type="xsd:string" use="optional" /> <xsd:attribute name="load-conditioning-interval" type="xsd:string" use="optional" /> <xsd:attribute name="keep-alive" type="xsd:string" use="optional" /> <xsd:attribute name="max-connections" type="xsd:string" use="optional" /> <xsd:attribute name="min-connections" type="xsd:string" use="optional" /> <xsd:attribute name="multi-user-authentication" type="xsd:string" use="optional" /> <xsd:attribute name="ping-interval" type="xsd:string" use="optional" /> <xsd:attribute name="pr-single-hop-enabled" type="xsd:string" use="optional" /> <xsd:attribute name="read-timeout" type="xsd:string" use="optional" /> <xsd:attribute name="retry-attempts" type="xsd:string" use="optional" /> <xsd:attribute name="server-group" type="xsd:string" use="optional" /> <xsd:attribute name="socket-buffer-size" type="xsd:string" use="optional" /> <xsd:attribute name="statistic-interval" type="xsd:string" use="optional" /> <xsd:attribute name="subscription-ack-interval" type="xsd:string" use="optional" /> <xsd:attribute name="subscription-enabled" type="xsd:string" use="optional" /> <xsd:attribute name="subscription-message-tracking-timeout" type="xsd:string" use="optional" /> <xsd:attribute name="subscription-redundancy" type="xsd:string" use="optional" /> <xsd:attribute name="thread-local-connections" type="xsd:string" use="optional" /> </xsd:complexType> </xsd:element> <!-- --> <xsd:element name="cache-server"> <xsd:annotation> <xsd:documentation source="org.springframework.data.gemfire.server.CacheServerFactoryBean"><![CDATA[ Defines a Cache Server for feeding data to remote gemfire clients to a server GemFire Cache Servers. Note: In order to instantiate a cacheserver, a GemFire cache needs to be avaialble in the VM. ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.server.CacheServer" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:complexType> <xsd:sequence minOccurs="0" maxOccurs="1"> <xsd:element name="subscription-config" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation><![CDATA[ The client subscription configuration that is used to control a clients use of server resources towards notification queues. ]]></xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:attribute name="eviction-type" use="optional" default="NONE"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="NONE" /> <xsd:enumeration value="MEM" /> <xsd:enumeration value="ENTRY" /> </xsd:restriction> </xsd:simpleType> </xsd:attribute> <xsd:attribute name="capacity" type="xsd:string" use="optional" default="1" /> <xsd:attribute name="disk-store" type="xsd:string" use="optional"/> </xsd:complexType> </xsd:element> </xsd:sequence> <xsd:attribute name="id" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the cache server definition (by default "gemfireServer"). ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="auto-startup" type="xsd:string" use="optional" default="true" /> <xsd:attribute name="bind-address" type="xsd:string" use="optional" /> <xsd:attribute name="port" type="xsd:string" use="optional" default="40404"> <xsd:annotation> <xsd:documentation><![CDATA[ The port number of the server. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="host-name-for-clients" type="xsd:string" use="optional" /> <xsd:attribute name="load-poll-interval" type="xsd:string" use="optional" default="5000" /> <xsd:attribute name="max-connections" type="xsd:string" use="optional" default="800" /> <xsd:attribute name="max-threads" type="xsd:string" use="optional" default="0" /> <xsd:attribute name="max-message-count" type="xsd:string" use="optional" default="230000" /> <xsd:attribute name="max-time-between-pings" type="xsd:string" use="optional" default="60000" /> <xsd:attribute name="message-time-to-live" type="xsd:string" use="optional" default="180" /> <xsd:attribute name="socket-buffer-size" type="xsd:string" use="optional" default="32768" /> <xsd:attribute name="notify-by-subscription" type="xsd:string" use="optional" default="true" /> <xsd:attribute name="groups" type="xsd:string" use="optional" default=""> <xsd:annotation> <xsd:documentation><![CDATA[ The server groups that this server will be a member of given as a comma separated values list. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="load-probe-ref" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the bean defining the CacheServer Load Probe. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="cache-ref" type="xsd:string" use="optional" default="gemfireCache"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the bean defining the GemFire cache (by default 'gemfireCache'). ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> </xsd:element> <!-- --> <xsd:element name="cq-listener-container"> <xsd:annotation> <xsd:documentation><![CDATA[ Container for continuous query listeners. All listeners will be hosted by the same container. ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="org.springframework.data.gemfire.listener.ContinuousQueryListenerContainer" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element name="listener" type="listenerType" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> <xsd:attribute name="id" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The id of the listener (optional) ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="cache" type="xsd:string" default="gemfireCache"> <xsd:annotation> <xsd:documentation><![CDATA[ A reference (by name) to the GemFire cache bean. Default is "gemfireCache". ]]></xsd:documentation> <xsd:appinfo> <tool:annotation kind="ref"> <tool:expected-type type="com.gemstone.gemfire.cache.RegionService" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> </xsd:attribute> <xsd:attribute name="task-executor" type="xsd:string"> <xsd:annotation> <xsd:documentation><![CDATA[ A reference to a Spring TaskExecutor (or standard JDK 1.5 Executor) for executing GemFire listener invokers. Default is a SimpleAsyncTaskExecutor. ]]></xsd:documentation> <xsd:appinfo> <tool:annotation kind="ref"> <tool:expected-type type="java.util.concurrent.Executor" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> </xsd:attribute> <xsd:attribute name="phase" type="xsd:string"> <xsd:annotation> <xsd:documentation><![CDATA[ The lifecycle phase within which this container should start and stop. The lower the value the earlier this container will start and the later it will stop. The default is Integer.MAX_VALUE meaning the container will start as late as possible and stop as soon as possible. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="pool-name" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the pool used by the container. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> </xsd:element> <!-- --> <xsd:complexType name="listenerType"> <xsd:attribute name="ref" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ The bean name of the listener object, implementing the ContinuousQueryListener interface or defining the specified listener method. Required. ]]></xsd:documentation> <xsd:appinfo> <tool:annotation kind="ref" /> </xsd:appinfo> </xsd:annotation> </xsd:attribute> <xsd:attribute name="query" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ The query for the GemFire continuous query. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="method" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the listener method to invoke. If not specified, the target bean is supposed to implement the ContinuousQueryListener interface or provide a method named 'handleEvent'. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="name" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the resulting GemFire continuous query. Useful for monitoring and statistics querying. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="durable" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Whether the resulting GemFire continuous query is durable or not. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> <!-- --> <xsd:element name="index"> <xsd:annotation> <xsd:documentation source="org.springframework.data.gemfire.IndexFactoryBean"><![CDATA[ Defines a GemFire index. ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.query.Index" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:complexType> <xsd:attribute name="id" type="xsd:string"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the index bean definition. If property 'name' is not set, it will be used as the index name as well. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="type" use="optional"> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="HASH" /> <xsd:enumeration value="PRIMARY_KEY" /> <xsd:enumeration value="FUNCTIONAL" /> </xsd:restriction> </xsd:simpleType> </xsd:attribute> <xsd:attribute name="name" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the index. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="expression" type="xsd:string" use="required" /> <xsd:attribute name="from" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ Corresponds to the regionPath parameter in createIndex methods. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="imports" type="xsd:string" use="optional" /> <xsd:attribute name="override" type="xsd:string" use="optional" default="true"> <xsd:annotation> <xsd:documentation><![CDATA[ Indicates whether the index is created even if there is an index with the same name (default) or not. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="cache-ref" type="xsd:string" use="optional" default="gemfireCache"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the bean defining the GemFire cache (by default 'gemfireCache'). ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="pool-name" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the pool used by the index. Used usually in client scenarios. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> </xsd:element> <!-- --> <xsd:complexType name="jndiBindingType"> <xsd:sequence> <xsd:element name="jndi-prop" type="configPropertyType" minOccurs="0" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies a vendor-specific property ]]></xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> <xsd:attribute name="jndi-name" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ The JNDI name for this datasource. Will be prefixed with "java:/" ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="type" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the datasource implementation: ManagedDataSource,SimpleDataSource,PooledDataSource,XaPooledDataSource ]]></xsd:documentation> </xsd:annotation> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="ManagedDataSource" /> <xsd:enumeration value="SimpleDataSource" /> <xsd:enumeration value="PooledDataSource" /> <xsd:enumeration value="XaPooledDataSource" /> </xsd:restriction> </xsd:simpleType> </xsd:attribute> <xsd:attribute name="blocking-timeout-seconds" type="xsd:string" use="optional" /> <xsd:attribute name="conn-pooled-datasource-class" type="xsd:string" use="optional" /> <xsd:attribute name="connection-url" type="xsd:string" use="optional" /> <xsd:attribute name="idle-timeout-seconds" type="xsd:string" use="optional" /> <xsd:attribute name="init-pool-size" type="xsd:string" use="optional" /> <xsd:attribute name="jdbc-driver-class" type="xsd:string" use="optional" /> <xsd:attribute name="login-timeout-seconds" type="xsd:string" use="optional" /> <xsd:attribute name="managed-connection-factory-class" type="xsd:string" use="optional" /> <xsd:attribute name="max-pool-size" type="xsd:string" use="optional" /> <xsd:attribute name="password" type="xsd:string" use="optional" /> <xsd:attribute name="user-name" type="xsd:string" use="optional" /> <xsd:attribute name="xa-datasource-class" type="xsd:string" use="optional" /> <xsd:attribute name="transaction-type" type="xsd:string" use="optional" /> </xsd:complexType> <!-- --> <xsd:complexType name="configPropertyType" mixed="true"> <xsd:attribute name="key" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies The property key ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="type" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies a data type if other than java.lang.String ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> <!-- --> <xsd:complexType name="baseGatewaySenderType"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.wan.GatewaySender"><![CDATA[ A gateway sender gateway definition (requires Gemfire 7.0 or later) ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.wan.GatewaySender" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:sequence> <xsd:element name="event-filter" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.wan.GatewayEventFilter"><![CDATA[ A gateway event filter for this gateway sender ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.wan.GatewayEventFilter" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation><![CDATA[ Inner bean definition of the event filter ]]></xsd:documentation> </xsd:annotation> </xsd:any> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="transport-filter" type="gatewayTransportFilterType" minOccurs="0" maxOccurs="1" /> </xsd:sequence> <xsd:attributeGroup ref="commonWANQueueAttributes" /> <xsd:attribute name="name" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Optionally specifies the GemFire gateway sender id. By default this value is the bean id or a generated value if an inner bean. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="remote-distributed-system-id" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the remote distributed system id, an integer value representing the remote distributed system ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="manual-start" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies if the gateway sender is manually (true) or automatically(false) started ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="socket-buffer-size" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the socket buffer size in bytes ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="socket-read-timeout" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the socket read timeout in milliseconds ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="enable-batch-conflation" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies whether batch conflation is enabled (true or false) ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="batch-time-interval" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The maximum time interval that can elapse before a partial batch is sent from a GatewaySender to its corresponding GatewayReceiver. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="alert-threshold" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the alert threshold in miliseconds, indicating the maximum time elapsed from when the gateway sent the message to when the acknowldgement was received from the gateway receiver. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="dispatcher-threads" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the number of dispatcher threads to allocate to the gateway sender ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="order-policy" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the order policy - This only applies if parallel is enabled: KEY: Indicates that events will be parallelized based on the event's key, PARTITION:Indicates that events will be parallelized based on the event's: partition (using the PartitionResolver) THREAD:Indicates that events will be parallelized based on the event's originating member and thread ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> <!-- --> <xsd:attributeGroup name="commonWANQueueAttributes"> <xsd:attribute name="batch-size" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the batch size ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="persistent" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies whether persistence is enabled: true or false(default) ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="disk-store-ref" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Indicates the id of disk store to use for persistence ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="maximum-queue-memory" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the maximum memory in MB to allocate for the queue ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="parallel" type="xsd:string"> <xsd:annotation> <xsd:documentation><![CDATA[ A value of "false" or "true" that specifies the type of queue GemFire creates, serial or parallel. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:attributeGroup> <!-- --> <xsd:complexType name="gatewayReceiverType"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.wan.GatewayReceiver"><![CDATA[ A gateway receiver definition (requires Gemfire 7.0 or later) ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.wan.GatewayReceiver" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:sequence> <xsd:element name="transport-filter" type="gatewayTransportFilterType" minOccurs="0" maxOccurs="1" /> </xsd:sequence> <xsd:attribute name="start-port" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the lower end of a port range to use for the gateway receiver ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="end-port" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the upper end of a port range to use for the gateway receiver ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="bind-address" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the bind address (IP address or host name) for the gateway receiver ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="maximum-time-between-pings" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the maximum time between pings in milliseconds ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="socket-buffer-size" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the socket buffer size in bytes ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="id" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The id of this bean definition ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="cache-ref" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The id of the cache - default is gemfireCache ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> <!-- --> <xsd:complexType name="baseAsyncEventQueueType"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.wan.AsyncEventQueue"><![CDATA[ An async event queue definition (requires Gemfire 7.0 or later) ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.wan.AsyncEventQueue" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:sequence> <xsd:element name="async-event-listener" minOccurs="1" maxOccurs="1"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.wan.AsyncEventListener"><![CDATA[ An async event listener definition for this distributed system. (requires Gemfire 7.0) ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.wan.AsyncEventListener" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation><![CDATA[ Inner bean definition of the async event listener ]]></xsd:documentation> </xsd:annotation> </xsd:any> </xsd:sequence> <xsd:attribute name="ref" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the async event listener bean referred by this declaration. Used as a convenience method. If no reference exists, use inner bean declarations. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> </xsd:element> </xsd:sequence> <xsd:attribute name="name" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Optionally specifies the GemFire async event queue id. By default this value is the bean id or a generated value if an inner bean. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="batch-conflation-enabled" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Optionally specifies whether to conflate queued events (true or false) (only available in Gemfire 7.0.1 + ) ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="batch-time-interval" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the maximum time interval that can elapse before a partial batch is sent from a the AsyncEventQueue (only available in Gemfire 7.0.1 + ) ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="disk-synchronous" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies if disk writes should be synchronous (true or false) (only available in Gemfire 7.0.1 + ) ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="dispatcher-threads" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the number of dispatcher threads to use (only available in Gemfire 7.0.1 + ) ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="order-policy" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ (Only available in GemFire 7.0.1 + ) Specifies the order policy - This only applies if parallel is enabled: KEY: Indicates that events will be parallelized based on the event's key, PARTITION:Indicates that events will be parallelized based on the event's: partition (using the PartitionResolver) THREAD:Indicates that events will be parallelized based on the event's originating member and thread ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attributeGroup ref="commonWANQueueAttributes" /> </xsd:complexType> <!-- --> <xsd:element name="gateway-sender"> <xsd:complexType> <xsd:complexContent> <xsd:extension base="baseGatewaySenderType"> <xsd:attribute name="id" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ The id of this bean definition. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="cache-ref" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The id of the cache - default is gemfireCache ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> <!-- --> <xsd:element name="async-event-queue"> <xsd:complexType> <xsd:complexContent> <xsd:extension base="baseAsyncEventQueueType"> <xsd:attribute name="id" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ The id of this bean definition. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="cache-ref" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The id of the cache - default is gemfireCache ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> <xsd:element name="gateway-receiver" type="gatewayReceiverType" /> <!-- --> <xsd:element name="function-service"> <xsd:complexType> <xsd:sequence> <xsd:element name="function" minOccurs="0" maxOccurs="1"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.execute.Function"><![CDATA[ Declares one or more remote functions for this cache and register's with them the FunctionService. each bean must implement com.gemstone.gemfire.cache.execute.Function ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.execute.Function" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation><![CDATA[ Inner bean definition of the remote function. ]]></xsd:documentation> </xsd:annotation> </xsd:any> </xsd:sequence> <xsd:attribute name="ref" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the remote function bean referred by this declaration. Used as a convenience method. If no reference exists, use inner bean declarations. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> </xsd:element> </xsd:sequence> <xsd:attribute name="id" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The id of the function service (optional) ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> </xsd:element> <!-- --> <xsd:simpleType name="scopeType"> <xsd:annotation> <xsd:documentation><![CDATA[ Determines how updates to region entries are distributed to the other caches in the distributed system where the region and entry are defined. Scope also determines whether to allow remote invocation of some of the region’s event handlers ]]></xsd:documentation> </xsd:annotation> <xsd:restriction base="xsd:string"> <xsd:enumeration value="distributed-ack" /> <xsd:enumeration value="distributed-no-ack" /> <xsd:enumeration value="global" /> </xsd:restriction> </xsd:simpleType> <xsd:complexType name="gatewayTransportFilterType"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.wan.GatewayTransportFilter"><![CDATA[ A transport filter for this gateway component ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.wan.GatewayTransportFilter" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:sequence> <xsd:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation><![CDATA[ Inner bean definition of the transport filter. ]]></xsd:documentation> </xsd:annotation> </xsd:any> </xsd:sequence> <xsd:attribute name="ref" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the transport filter bean referred by this declaration. Used as a convenience method. If no reference exists, use inner bean declarations. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> <!-- Gemfire 6 WAN Gateway schema --> <xsd:complexType name="gatewayHubType"> <xsd:annotation> <xsd:documentation><![CDATA[ Deprecated as of Gemfire 7 ]]></xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:element name="gateway" type="gatewayType" minOccurs="0" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation><![CDATA[ Deprecated as of Gemfire 7 ]]></xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> <xsd:attribute name="id" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ The id of this hub ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="port" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The port for this hub (integer value, if not specified, Gemfire will select an open port) ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="cache-ref" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The id of the cache - default is gemfireCache ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="bind-address" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the bind address (IP address or host name) for the gateway hub ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="socket-buffer-size" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the socket buffer size in bytes ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="manual-start" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies if the gateway hub is manually (true) or automatically(false) started ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="startup-policy" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the startup policy (primary,secondary, none) for the gateway hub ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> <!-- --> <xsd:complexType name="gatewayEndpointType"> <xsd:annotation> <xsd:documentation><![CDATA[ Deprecated as of Gemfire 7 ]]></xsd:documentation> </xsd:annotation> <xsd:attribute name="host" type="xsd:string" use="required"> </xsd:attribute> <xsd:attribute name="port" type="xsd:string" use="required"> </xsd:attribute> <xsd:attribute name="endpoint-id" type="xsd:string" use="required"> </xsd:attribute> </xsd:complexType> <!-- --> <xsd:complexType name="gatewayQueueType"> <xsd:annotation> <xsd:documentation><![CDATA[ Deprecated as of Gemfire 7 ]]></xsd:documentation> </xsd:annotation> <xsd:attribute name="enable-batch-conflation" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies whether batch conflation is enabled (true or false) ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="batch-time-interval" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The maximum time interval that can elapse before a partial batch is sent from a GatewaySender to its corresponding GatewayReceiver. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="alert-threshold" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the alert threshold in miliseconds, indicating the maximum time elapsed from when the gateway sent the message to when the acknowldgement was received from the gateway receiver. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="batch-size" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the batch size ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="persistent" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies whether persistence is enabled: true or false(default) ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="disk-store-ref" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Indicates the id of disk store to use for persistence ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="maximum-queue-memory" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the maximum memory in MB to allocate for the queue ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> <!-- --> <xsd:complexType name="gatewayType"> <xsd:annotation> <xsd:documentation><![CDATA[ Deprecated as of Gemfire 7 ]]></xsd:documentation> </xsd:annotation> <xsd:sequence> <xsd:choice> <xsd:element name="gateway-endpoint" minOccurs="1" maxOccurs="unbounded" type="gatewayEndpointType" /> <xsd:element name="gateway-listener" minOccurs="1" maxOccurs="1"> <xsd:annotation> <xsd:documentation source="com.gemstone.gemfire.cache.util.GatewayEventListener"><![CDATA[ An gateway event listener definition for the gateway ]]></xsd:documentation> <xsd:appinfo> <tool:annotation> <tool:exports type="com.gemstone.gemfire.cache.util.GatewayEventListener" /> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation><![CDATA[ Inner bean definition of the gateway event listener ]]></xsd:documentation> </xsd:annotation> </xsd:any> </xsd:sequence> <xsd:attribute name="ref" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ The name of the gateway event listener bean referred by this declaration. Used as a convenience method. If no reference exists, use inner bean declarations. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> </xsd:element> </xsd:choice> <xsd:element name="gateway-queue" minOccurs="0" maxOccurs="1" type="gatewayQueueType" /> </xsd:sequence> <xsd:attribute name="gateway-id" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the id for this gateway ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="socket-buffer-size" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the socket buffer size in bytes ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="socket-read-timeout" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the socket read timeout in milliseconds ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="order-policy" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the order policy - This only applies if parallel is enabled: KEY: Indicates that events will be parallelized based on the event's key, PARTITION:Indicates that events will be parallelized based on the event's: partition (using the PartitionResolver) THREAD:Indicates that events will be parallelized based on the event's originating member and thread ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="concurrency-level" type="xsd:string" use="optional"> <xsd:annotation> <xsd:documentation><![CDATA[ Specifies the number of parallel threads ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> <!-- --> <xsd:element name="gateway-hub" type="gatewayHubType"> <xsd:annotation> <xsd:documentation><![CDATA[ Deprecated as of Gemfire 7 ]]></xsd:documentation> </xsd:annotation> </xsd:element> <!-- End Gemfire 6 WAN Gateway schema --> <!-- Function Annotation Support --> <xsd:element name="annotation-driven"> <xsd:annotation> <xsd:documentation><![CDATA[ Enables gemfire annotations. ]]></xsd:documentation> </xsd:annotation> </xsd:element> </xsd:schema>
Spring Data GemFire Data Access Schema (gfe-data)
<?xml version="1.0" encoding="UTF-8" standalone="no"?> <xsd:schema xmlns="http://www.springframework.org/schema/data/gemfire" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:beans="http://www.springframework.org/schema/beans" xmlns:tool="http://www.springframework.org/schema/tool" xmlns:repository="http://www.springframework.org/schema/data/repository" xmlns:context="http://www.springframework.org/schema/context" xmlns:gfe="http://www.springframework.org/schema/gemfire" targetNamespace="http://www.springframework.org/schema/data/gemfire" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.3"> <xsd:import namespace="http://www.springframework.org/schema/beans"/> <xsd:import namespace="http://www.springframework.org/schema/tool"/> <xsd:import namespace="http://www.springframework.org/schema/data/repository" schemaLocation="http://www.springframework.org/schema/data/repository/spring-repository.xsd"/> <xsd:import namespace="http://www.springframework.org/schema/gemfire" schemaLocation="http://www.springframework.org/schema/gemfire/spring-gemfire.xsd"/> <xsd:import namespace="http://www.springframework.org/schema/context" schemaLocation="http://www.springframework.org/schema/context/spring-context.xsd" /> <!-- --> <xsd:annotation> <xsd:documentation><![CDATA[ Namespace support for the Spring Data GemFire Client side data access. ]]></xsd:documentation> </xsd:annotation> <!-- --> <!-- Repositories --> <xsd:element name="repositories"> <xsd:complexType> <xsd:complexContent> <xsd:extension base="repository:repositories"> <xsd:attributeGroup ref="gemfire-repository-attributes"/> <xsd:attributeGroup ref="repository:repository-attributes"/> </xsd:extension> </xsd:complexContent> </xsd:complexType> </xsd:element> <!-- --> <xsd:element name="function-executions"> <xsd:annotation> <xsd:documentation><![CDATA[ Enables component scanning for annotated function execution interfaces. ]]></xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence> <xsd:element name="include-filter" type="context:filterType" minOccurs="0" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation><![CDATA[ Controls which eligible types to include for component scanning. ]]></xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element name="exclude-filter" type="context:filterType" minOccurs="0" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation><![CDATA[ Controls which eligible types to exclude for component scanning. ]]></xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> <xsd:attribute name="base-package" type="xsd:string" use="required"> <xsd:annotation> <xsd:documentation><![CDATA[ Defines the base package where function execution interfaces will be tried to be detected. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> </xsd:element> <!-- --> <xsd:attributeGroup name="gemfire-repository-attributes"> <xsd:attribute name="mapping-context-ref" type="mappingContextRef"> <xsd:annotation> <xsd:documentation> The reference to a MappingContext. If not set a default one will be created. </xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:attributeGroup> <!-- --> <xsd:simpleType name="mappingContextRef"> <xsd:annotation> <xsd:appinfo> <tool:annotation kind="ref"> <tool:assignable-to type="org.springframework.data.gemfire.GemfireMappingContext"/> </tool:annotation> </xsd:appinfo> </xsd:annotation> <xsd:union memberTypes="xsd:string"/> </xsd:simpleType> <!-- DataSource --> <xsd:element name="datasource"> <xsd:annotation> <xsd:documentation><![CDATA[ Defines a connection from a Cache client to a set of GemFire Cache Servers. ]]></xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:choice minOccurs="1" maxOccurs="1"> <xsd:element name="locator" type="gfe:connectionType" minOccurs="1" maxOccurs="unbounded" /> <xsd:element name="server" type="gfe:connectionType" minOccurs="1" maxOccurs="unbounded" /> </xsd:choice> <xsd:attribute name="free-connection-timeout" type="xsd:string" use="optional" /> <xsd:attribute name="idle-timeout" type="xsd:string" use="optional" /> <xsd:attribute name="load-conditioning-interval" type="xsd:string" use="optional" /> <xsd:attribute name="max-connections" type="xsd:string" use="optional" /> <xsd:attribute name="min-connections" type="xsd:string" use="optional" /> <xsd:attribute name="multi-user-authentication" type="xsd:string" use="optional" /> <xsd:attribute name="ping-interval" type="xsd:string" use="optional" /> <xsd:attribute name="pr-single-hop-enabled" type="xsd:string" use="optional" /> <xsd:attribute name="read-timeout" type="xsd:string" use="optional" /> <xsd:attribute name="retry-attempts" type="xsd:string" use="optional" /> <xsd:attribute name="server-group" type="xsd:string" use="optional" /> <xsd:attribute name="socket-buffer-size" type="xsd:string" use="optional" /> <xsd:attribute name="statistic-interval" type="xsd:string" use="optional" /> <xsd:attribute name="subscription-ack-interval" type="xsd:string" use="optional" /> <xsd:attribute name="subscription-enabled" type="xsd:string" use="optional" /> <xsd:attribute name="subscription-message-tracking-timeout" type="xsd:string" use="optional" /> <xsd:attribute name="subscription-redundancy" type="xsd:string" use="optional" /> <xsd:attribute name="thread-local-connections" type="xsd:string" use="optional" /> </xsd:complexType> </xsd:element> <xsd:element name="json-region-autoproxy"> <xsd:annotation> <xsd:documentation><![CDATA[ Enables A Spring AOP proxy to perform automatic conversion to and from JSON for appropriate region operations ]]></xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:attribute name="region-refs" use="optional" type="xsd:string"> <xsd:annotation> <xsd:documentation><![CDATA[ A comma delimited string of region names to include for JSON conversion. By default all regions are included. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="pretty-print" use="optional" type="xsd:string"> <xsd:annotation> <xsd:documentation><![CDATA[ A boolean value to specify whether returned JSON strings are pretty printed, false by default. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> <xsd:attribute name="convert-returned-collections" use="optional" type="xsd:string"> <xsd:annotation> <xsd:documentation><![CDATA[ A boolean value to specify whether Collections returned by Region.getAll(), Region.values() should be converted from the native GemFire PdxInstance type. True, by default but will incur significant overhead for large collections. ]]></xsd:documentation> </xsd:annotation> </xsd:attribute> </xsd:complexType> </xsd:element> </xsd:schema>