Once the GemFire cache and regions have been configured, these can injected and used inside application objects. This chapter describes the integration with the Spring transaction management, DaoException hierarchy and wiring of GemFire managed objects.

Using a new API requires not just accommodating to the new semantics but also handling its particular exception set. To accommodate this case, Spring Framework provides a generic, consistent exception hierarchy that abstracts one from proprietary (and usually checked) exceptions to a set of focused runtime exceptions. As mentioned in the Spring Framework documentation, by using annotations (@Repository) or AOP, exception translations happens automatically without any code changes. The same holds true for GemFire as long as at least a CacheFactoryBean is declared. The Cache factory acts as an exception translator which is automatically detected by the Spring infrastructure and used accordingly.

One of the most popular features of Spring Framework is transaction management. If you are not familiar with it, we strongly recommend looking into it as it offers a consistent programming model that works transparently across multiple API that can be configured either programmatically or declaratively (the most popular choice). For Gemfire, SGI provides a dedicated, per-cache, transaction manager that once declared, allows actions on the Regions to be grouped and executed atomically through Spring: ]]> Note that currently GemFire supports optimistic transactions with read committed isolation. Further more to guarantee this isolation, developers should avoid making in-place changes, that is manually modifying the values present in the cache. To prevent this from happening, the transaction manager configured the cache to use copy on read semantics, meaning a clone of the actual value is created, each time a read is performed. This behaviour 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.

GemFire XML configuration (usually named cache.xml allows user objects to be declared as part of the fabric config. Usually these objects are CacheLoaders or other pluggable components into GemFire. Out of the box, each such type declared through XML must implement the Declarable interface which allows arbitrary parameters to be passed to the declared class through a Properties instance. One can configure custom types entirely inside through Spring as mentioned in . That way, one does not have to implement the Declarable interface and gets access to all the features of the Spring IoC container (including not just dependency injection but also life-cycle and instance management). Consider the following declaration (taken from the Declarable javadoc): com.company.app.DBLoader jdbc://12.34.56.78/mydb ]]> To simplify the task of parsing, converting the parameters and initializing the object, SGI offers a base class (WiringDeclarableSupport) that allows GemFire user objects to be wired through autowiring or based on declarations available inside the Spring container. To take advantage of this feature, the user objects need to extends WiringDeclarableSupport which automatically locates the declaring BeanFactory and performs wiring as part of the initialization process. Unfortunately, in the current GemFire release there is no concept of an object factory and the types declared are instantiated and used as is - that is there are no other ways in which third parties can take care of the object creation outside GemFire. This feature is planned for the up-coming GemFire release (6.5)

If no parameters are given, WiringDeclarableSupport will autowire the declaring instance. In short, this means that unless any 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: com.company.app.DBLoader ]]> ]]> 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.

For cases where auto/annotation-wiring is not enough (or not an option), one can instruct SGI class to use an existing bean definition as a template for wiring. Let's see how our DBLoader declaration would look in that case: com.company.app.DBLoader template-bean ]]> ]]> The template bean definitions do not have to be declared in XML - any format is allowed (Groovy, annotations, etc..).