SGF-339 - Change all VMWare-based links in the SDG Reference Guide to Pivotal-based links.

(cherry picked from commit 9af336af32)

Signed-off-by: John Blum <jblum@pivotal.io>
This commit is contained in:
John Blum
2014-10-10 14:40:41 -07:00
parent 5df3d2e5ae
commit bc1670b9be
11 changed files with 28 additions and 25 deletions

View File

@@ -1,5 +1,5 @@
[[requirements]]
= Requirements
Spring Data GemFire requires JDK 6.0 or above, http://www.springsource.org/about[Spring Framework] 3 and http://www.vmware.com/support/pubs/vfabric-gemfire.html[Pivotal GemFire] 6.6 or above (version 7 or above is recommended).
Spring Data GemFire requires JDK 6.0 or above, http://projects.spring.io/spring-framework[Spring Framework] 3 and http://www.pivotal.io/big-data/pivotal-gemfire[Pivotal GemFire] 6.6 or above (version 7 or above is recommended).

View File

@@ -2,8 +2,11 @@
= Useful Links
* http://projects.spring.io/spring-data-gemfire[Spring Data GemFire Home Page]
* http://www.vmware.com/products/application-platform/vfabric-gemfire/overview.html[Pivotal GemFire Home Page]
* https://www.vmware.com/support/pubs/vfabric-gemfire.html[Pivotal GemFire Documentation]
* http://communities.vmware.com/community/vmtn/appplatform/vfabric_gemfire[Pivotal GemFire Community Home Page]
* http://forum.spring.io/forum/spring-projects/data/gemfire[Spring Data GemFire Forum<]
* http://www.pivotal.io/big-data/pivotal-gemfire[Pivotal GemFire Home Page]
* http://gemfire.docs.pivotal.io/index.html[Pivotal GemFire Documentation]
* https://support.pivotal.io/hc/en-us/categories/200072748-Pivotal-GemFire-Knowledge-Base[Pivotal GemFire Knowledge Base]
* https://support.pivotal.io/hc/communities/public/topics/200053218-Pivotal-GemFire-General[Pivotal GemFire Community Home Page]
* http://communities.vmware.com/community/vmtn/appplatform/vfabric_gemfire[VMWare vFabric GemFire Community Home Page]
* http://stackoverflow.com/questions/tagged/spring-data-gemfire[Spring Data GemFire Forum (StackOverflow)]
* http://forum.spring.io/forum/spring-projects/data/gemfire[Spring Data GemFire Forum (spring.io archive)]

View File

@@ -3,7 +3,7 @@
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 http://www.vmware.com/products/application-platform/vfabric-gemfire[product] documentation.
NOTE: This section assumes basic familiarity with GemFire. For more information see the http://www.pivotal.io/big-data/pivotal-gemfire[product] documentation.
[[bootstrap:region:spring:config]]
== Advantages of using Spring over GemFire `cache.xml`

View File

@@ -32,7 +32,7 @@ In this example, if the cache needs to be created, it will use the file named `c
NOTE: Note that the configuration makes use of Spring's http://static.springsource.org/spring/docs/current/spring-framework-reference/html/resources.html[`Resource`] abstraction to locate the file. This allows various search patterns to be used, depending on the runtime environment or the prefix specified (if any) in the resource location.
In addition to referencing an external configuration file one can specify GemFire http://pubs.vmware.com/vfabricNoSuite/topic/com.vmware.vfabric.gemfire.7.0/reference/topics/gemfire_properties.html[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:
In addition to referencing an external configuration file one can specify GemFire http://gemfire.docs.pivotal.io/latest/userguide/index.html#reference/topics/gemfire_properties.html[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:
[source,xml]
----
@@ -89,12 +89,12 @@ For advanced cache configuration, the `cache` element provides a number of confi
----
<1> Various cache options are supported by attributes. For further information regarding anything shown in this example, please consult the GemFire product http://www.vmware.com/support/pubs/vfabric-gemfire.html[documentation]
<1> Various cache options are supported by attributes. For further information regarding anything shown in this example, please consult the GemFire product http://gemfire.docs.pivotal.io/index.html[documentation]
The `close` attribute determines if the cache should be closed when the Spring application context is closed. The default is `true` however for cases in which multiple application contexts use the cache (common in web applications), set this value to `false`.
The `lazy-init` attribute determines if the cache should be initialized before another bean references it. The default is `true` however in some cases it may be convenient to set this value to `false`.
<2> An example of a `TransactionListener` callback declaration using a bean reference. The referenced bean must implement http://www.vmware.com/support/developer/vfabric-gemfire/700-api/com/gemstone/gemfire/cache/TransactionListener.html[TransactionListener]
<3> An example of a `TransactionWriter` callback declaration using an inner bean declaration this time. The bean must implement http://www.vmware.com/support/developer/vfabric-gemfire/700-api/com/gemstone/gemfire/cache/TransactionWriter.html[TransactionWriter]
<4> Enable GemFire's http://www.vmware.com/support/developer/vfabric-gemfire/700-api/com/gemstone/gemfire/cache/DynamicRegionFactory.html[DynamicRegionFactory]
<2> An example of a `TransactionListener` callback declaration using a bean reference. The referenced bean must implement http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/TransactionListener.html[TransactionListener]
<3> An example of a `TransactionWriter` callback declaration using an inner bean declaration this time. The bean must implement http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/TransactionWriter.html[TransactionWriter]
<4> Enable GemFire's http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/DynamicRegionFactory.html[DynamicRegionFactory]
<5> 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
@@ -113,7 +113,7 @@ The example above includes a number of attributes related to GemFire's enhanced
[[bootstrap:cache:server]]
== Configuring a GemFire Cache Server
In Spring Data GemFire 1.1 dedicated support for configuring a http://www.vmware.com/support/developer/vfabric-gemfire/700-api/com/gemstone/gemfire/cache/server/CacheServer.html[CacheServer] was added, allowing complete configuration through the Spring container:
In Spring Data GemFire 1.1 dedicated support for configuring a http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/server/CacheServer.html[CacheServer] was added, allowing complete configuration through the Spring container:
[source,xml]
----
@@ -152,7 +152,7 @@ NOTE: To avoid initialization problems, the `CacheServer`s started by Spring Dat
[[bootstrap:cache:client]]
== Configuring a GemFire Client Cache
Another configuration addition in Spring Data GemFire 1.1 is the dedicated support for configuring http://www.vmware.com/support/developer/vfabric-gemfire/700-api/com/gemstone/gemfire/cache/client/ClientCache.html[ClientCache]. This is similar to a <<bootstrap:cache,cache>> in both usage and definition and supported by `org.springframework.data.gemfire.clientClientCacheFactoryBean`.
Another configuration addition in Spring Data GemFire 1.1 is the dedicated support for configuring http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/client/ClientCache.html[ClientCache]. This is similar to a <<bootstrap:cache,cache>> in both usage and definition and supported by `org.springframework.data.gemfire.clientClientCacheFactoryBean`.
[source,xml]
----
@@ -176,7 +176,7 @@ Pools can be defined through the `pool` element; The client side `pool` can be u
</beans>
----
The <client-cache> tag also includes a `ready-for-events` attribute. If set to `true`, the client cache initialization will include http://www.vmware.com/support/developer/vfabric-gemfire/700-api/com/gemstone/gemfire/cache/client/ClientCache.html#readyForEvents()[ClientCache.readyForEvents()].
The <client-cache> tag also includes a `ready-for-events` attribute. If set to `true`, the client cache initialization will include http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/client/ClientCache.html#readyForEvents()[ClientCache.readyForEvents()].
Client side configuration is covered in more detail in <<bootstrap:region:client>>.

View File

@@ -17,7 +17,7 @@ The container is fully customizable - one can chose either to use the CQ thread
[[apis:cq-container:adapter]]
== The `ContinuousQueryListenerAdapter` and `ContinuousQueryListener`
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 https://www.vmware.com/support/developer/vfabric-gemfire/700-api/com/gemstone/gemfire/cache/query/CqListener.html[CqListener].
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 http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/query/CqListener.html[CqListener].
Consider the following interface definition. Notice the various event handling methods and their parameters:

View File

@@ -79,7 +79,7 @@ For GemFire, Spring Data GemFire provides a dedicated, per-cache, transaction ma
NOTE: The example above can be simplified even more by eliminating the `cache-ref` attribute if the GemFire Cache is defined under the default name`gemfireCache`. 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 is`gemfireTransactionManager` 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 https://www.vmware.com/support/developer/vfabric-gemfire/700-api/com/gemstone/gemfire/cache/CacheTransactionManager.html[documentation].
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 http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/CacheTransactionManager.html[documentation].
:leveloffset: +1
include::cq-container.adoc[]

View File

@@ -3,13 +3,13 @@
== Introduction
Spring Data GemFire 1.3.0 introduces annotation support to simplify working with http://pubs.vmware.com/vfabricNoSuite/index.jsp?topic=/com.vmware.vfabric.gemfire.7.0/developing/function_exec/chapter_overview.html??[GemFire function execution]. The GemFire API provides classes to implement and register https://www.vmware.com/support/developer/vfabric-gemfire/700-api/com/gemstone/gemfire/cache/execute/Function.html[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.
Spring Data GemFire 1.3.0 introduces annotation support to simplify working with http://gemfire.docs.pivotal.io/latest/userguide/index.html#developing/function_exec/chapter_overview.html[GemFire function execution]. The GemFire API provides classes to implement and register http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/execute/Function.html[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.
== Implementation vs Execution
There are two separate concerns to address. First is the function implementation (server) which must interact with the https://www.vmware.com/support/developer/vfabric-gemfire/700-api/com/gemstone/gemfire/cache/execute/FunctionContext.html[FunctionContext] to obtain the invocation arguments, the https://www.vmware.com/support/developer/vfabric-gemfire/700-api/com/gemstone/gemfire/cache/execute/ResultSender.html[ResultsSender] and other execution context information. The function implementation typically accesses the Cache and or Region and is typically registered with the https://www.vmware.com/support/developer/vfabric-gemfire/700-api/com/gemstone/gemfire/cache/execute/FunctionService.html[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 https://www.vmware.com/support/developer/vfabric-gemfire/700-api/com/gemstone/gemfire/cache/execute/Execution.html[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 https://www.vmware.com/support/developer/vfabric-gemfire/700-api/com/gemstone/gemfire/cache/execute/ResultCollector.html[ResultCollector] to aggregate and acquire the execution results. In certain scenarios, a custom ResultCollector implementation is required and may be registered with the Execution.
There are two separate concerns to address. First is the function implementation (server) which must interact with the http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/execute/FunctionContext.html[FunctionContext] to obtain the invocation arguments, the http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/execute/ResultSender.html[ResultsSender] and other execution context information. The function implementation typically accesses the Cache and or Region and is typically registered with the http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/execute/FunctionService.html[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 http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/execute/Execution.html[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 http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/execute/ResultCollector.html[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
@@ -92,7 +92,7 @@ A process invoking a remote function needs to provide calling arguments, a funct
=== Annotations for Function Execution
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 https://www.vmware.com/support/developer/vfabric-gemfire/700-api/com/gemstone/gemfire/cache/execute/ResultCollector.html[ResultCollector] to use for the execution.
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 http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/execute/ResultCollector.html[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.

View File

@@ -1,7 +1,7 @@
[[bootstrap:function]]
= Configuring GemFire's Function Service
As of Release 1.3.0, Spring Data GemFire provides <<function-annotations,annotation>> support for implementing and registering functions. Spring Data GemFire also provides namespace support for registering GemFire https://www.vmware.com/support/developer/vfabric-gemfire/700-api/com/gemstone/gemfire/cache/execute/Function.html[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:
As of Release 1.3.0, Spring Data GemFire provides <<function-annotations,annotation>> support for implementing and registering functions. Spring Data GemFire also provides namespace support for registering GemFire http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/cache/execute/Function.html[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:
[source,xml]
----

View File

@@ -5,15 +5,15 @@
Normally, a Spring-based application will <<bootstrap,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 http://pubs.vmware.com/vfabric53/topic/com.vmware.vfabric.gemfire.7.0/tools_modules/gfsh/chapter_overview.html[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.
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 http://gemfire.docs.pivotal.io/latest/userguide/index.html#tools_modules/gfsh/chapter_overview.html[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.
== Using GemFire to Bootstrap a Spring Context Started with Gfsh
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 http://pubs.vmware.com/vfabric53/topic/com.vmware.vfabric.gemfire.7.0/basic_config/the_cache/setting_cache_initializer.html[Initalizer] functionality. An *Initializer* can be used to specify a callback application that is launched after the Cache is initialized by GemFire.
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 http://gemfire.docs.pivotal.io/latest/userguide/index.html#basic_config/the_cache/setting_cache_initializer.html[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 http://pubs.vmware.com/vfabric53/topic/com.vmware.vfabric.gemfire.7.0/reference/topics/cache_xml.html?path=4_1_9_1_2_21#initializer[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="..."/>`)
An *Initializer* is specified within an http://gemfire.docs.pivotal.io/latest/userguide/index.html#reference/topics/cache_xml.html#initializer[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:

View File

@@ -747,7 +747,7 @@ A special key `ALL_KEYS` means interest is registered for all keys (identical to
[[bootstrap:region:json]]
== JSON Support
Gemfire 7.0 introduced support for caching JSON documents with OQL query support. These are stored internally as http://gemfire.docs.pivotal.io/7.0.2/javadocs/japi/com/gemstone/gemfire/pdx/PdxInstance.html[PdxInstance] types using the http://www.vmware.com/support/developer/vfabric-gemfire/700-api/com/gemstone/gemfire/pdx/JSONFormatter.html[JSONFormatter] to perform conversion to and from JSON strings. Spring Data GemFire provides a `<gfe-data:json-region-autoproxy/>` tag to enable a http://static.springsource.org/spring/docs/current/spring-framework-reference/htmlsingle/#aop-introduction[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.
Gemfire 7.0 introduced support for caching JSON documents with OQL query support. These are stored internally as http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/pdx/PdxInstance.html[PdxInstance] types using the http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/pdx/JSONFormatter.html[JSONFormatter] to perform conversion to and from JSON strings. Spring Data GemFire provides a `<gfe-data:json-region-autoproxy/>` tag to enable a http://static.springsource.org/spring/docs/current/spring-framework-reference/htmlsingle/#aop-introduction[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.

View File

@@ -6,7 +6,7 @@ To improve overall performance of the data grid, GemFire supports a dedicated se
[[serialization:wiring]]
== Wiring deserialized instances
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 https://www.vmware.com/support/developer/vfabric-gemfire/700-api/com/gemstone/gemfire/Instantiator.html[`Instantiator`] that performs wiring for each new instance created by GemFire during deserialization.
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 http://gemfire.docs.pivotal.io/latest/javadocs/japi/com/gemstone/gemfire/Instantiator.html[`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 http://static.springsource.org/spring/docs/current/spring-framework-reference/html/aop.html#aop-atconfigurable[`@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 (<<apis:declarable>>) for more details on wiring functionality.