Chapter 11. Playing Well with Others

Technology stacks have evolved into precise and broad choices, with numerous libraries and their dependencies all bundled together to support our applications. To help integrate into this wild ecosystem of technologies, Hazelcast provides us with some support to use and extend a few popularly used libraries, as well as to provide implementations of standardized interfaces.

In this chapter, we shall cover the following topics:

• Using dependency injection to help set up our cluster

• Working with a popular data layer for caching to help bridge the gap between traditional databases and the new world of Hazelcast

• Using external database persistence for Hazelcast collections to bridge the gap in the opposite direction

• Providing an alternative distributed session store for web applications

• Developing against the industry standard caching interface, JCache

• Looking at how to monitor and support our cluster

Don't pass what you need, depend on it

Most of the examples that we have developed so far have created HazelcastInstance that we use to programmatically access various collections and features of the cluster. However, as we begin to move away from simple conceptual examples, we will need to start passing references to various collections around our application in order to access data. This poses the age-old problem of how to avoid passing around the supporting dependencies of the application layers but still having access to them, when and where required. Luckily, this problem has already been solved for us in the form of dependency injection. Rather than reinventing the wheel, we should be able to use this existing technology to help solve this problem.

One of the most popular application frameworks providing DI is Spring, and Hazelcast features provide complimentary support for this framework, allowing us to configure our cluster as part of the standard Spring application context. To enable...

Transparently caching others' data

Another very popularly used framework is Hibernate, which is used as an Object Relational Mapper (ORM) layer and is traditionally used to translate objects to and from a relational database table. While this goes against the distributed data philosophy that we have been exploring with Hazelcast, we may have a legacy application that is currently using it. By adding a caching layer, we can improve the scalability and performance of this application. However, by enabling this cache layer, we will be introducing a data consistency issue; to avoid this, we would need an intelligent distributed cache, exactly like Hazelcast.

To enable the use of the cache layer, we must again include the appropriate library. This slightly varies depending on what version of Hibernate we are using, but depending on our version of Hibernate, we need to add a hazelcast-hibernate(3/4)-3.5.jar extension to the classpath. Additionally, we need to turn on Hibernate's second-level caching...

Cacheable methods with the Spring cache

While the caching layer provided as part of Hibernate unlocks easy and convenient caching for high-frequency or high-cost data, caching at a higher level, or more generally, method calls, can be expensive too.

Newer versions of the Spring framework (since version 3.1) feature the ability to transparently cache method calls and their returned results through the use of the com.hazelcast.spring.cache.HazelcastCacheManager class, and its registration as a Spring cache manager.

<cache:annotation-driven cache-manager="cacheManager" />

<bean id="cacheManager"
  class="com.hazelcast.spring.cache.HazelcastCacheManager">

  <constructor-arg ref="hzInstance"/>
</bean>

With this in place, we can then mark appropriate methods as @Cacheable, and where required, use @CacheEvict to trigger cache invalidations.

Caching by standard

As our applications have scaled up and beyond, caching has become more commonplace in various technologies. As we have seen from our earlier examples, there are lots of different ways and libraries to help us cache data within our application. However, most of these libraries use their own self-defined interfaces, so what if we want to move between technologies? As we have seen earlier, JPA provides a standardized way to persistently store data, with a number of technologies providing compliant implementations, so what if there was an equivalent for relatively short-term cache data?

Well, now, there is, in the form of the long awaited standard, JCache.

In order to use it, first, we will need to add the JCache API library to our classpath; if we are using a dependency manager such as Maven, this should be pretty trivial.

<dependency>
  <groupId>javax.cache</groupId>
  <artifactId>cache-api</artifactId>
  <version>1.0.0</version>
...

Collection persistence

Just as using Hazelcast to provide a distributed caching layer in front of our traditional database, we can also invert this relationship. By having Hazelcast as the primary data store, we can configure MapStore to provide the long-term persistence of stored objects, working around the potential risk of data resilience due to Hazelcast's in-memory nature.

This resilience, however, does come at a cost to performance and scalability. This means that we have to update an external system upon each change to the cluster data. However, we can configure the method of this process as synchronous (where data is written out to the store prior to returning confirmation to the client) or asynchronous (where this process happens in the background shortly afterwards) through the use of the write-delay-seconds configuration. A zero value indicates synchronous persistence, and a positive value determines the delay before the asynchronous process kicks in.

So, an example map configuration...

Web session storage

Another complementary piece of functionality is the ability to provide session persistence to a web application. This is normally provided by the application container but typically has replication or scalability issues with large deployments. This problem tends to be addressed through the use of sticky sessions, where a load balancer sits in front of the application route-related traffic to the same container, but what would happen in a failure situation? If the container does not feature any form of replication, the session will be lost and a negative customer experience will be encountered.

Hazelcast can help address this issue by providing an external and distributed session store for our application. By including hazelcast-wm-3.5.jar in our web application and configuring the web.xml file, we can provide session persistence by using a web application filter. In the case that your application uses multiple filters, make sure that this is the first filter defined within...

Cluster management

Throughout this book, we have seen how to set up and use Hazelcast to support our application, but once we start using it, we will need to maintain and support our cluster. While we can gain great insight into the goings on programmatically, this will take some effort to capture and control all aspects of the cluster. A part of our downloaded archive is Hazelcast's own management center (mancenter-3.5.war), which provides access to cluster and collection information as well as management and support capabilities. While this is a commercial product, it is currently free to be used with a cluster of up to two nodes.

JMX statistics

If we want to have more ownership of our cluster's monitoring potential integrated into our own monitoring and alerts infrastructure, we can additionally expose metrics via a JMX interface directly provided by each Hazelcast instance. We can then use the capturing capabilities provided by technologies such as collected or Munin to harvest, store...

Summary

Here, we can see that Hazelcast has again attempted to integrate well into a software library ecosystem, knowing that the same wheel has probably already been invented somewhere else in order to solve various problems or provide a particular functionality. Being able to work well with other popular existing frameworks makes bringing this powerful new technology into our existing stack a much smoother process.

As we have seen throughout this book, this great technology provides us with a flexible, extensible, and dynamic data source, enabling us to build data stores and structures that are truly distributed without any single point of failure. We can use various generic collections to hold our data in appropriate ways, be it for key value storage, FIFO queuing, or providing a mechanism for cluster-wide communication. It also provides us with additional complimentary capabilities that will normally be crowbarred into other centralized services (for example, using database row locking...