Java Reference
In-Depth Information
Clustering the Ticket example
which was built around the following:
• A stateful EJB to hold the session data
• A singleton EJB to store the cache of data
• A stateless EJB to perform some business methods
Let's see how to apply the necessary changes to start our application in a cluster context.
The stateless and stateful beans are ready to be clustered—no additional code is required;
however, there's a pitfall. As a matter of fact, the singleton EJB that is used to hold the
cache of a seat will be instantiated once in each JVM of the cluster. This means that if
there's a server failure, the data in the cache will be lost and new data (inconsistent) will
be used.
There are several alternatives to set up a cache in a clustered environment:
• Use a JBoss proprietary solution that deploys a clustered version of
SingletonService
, which exposes an HA singleton of
org.jboss.msc.service.Service
(an example of this approach is con-
tained in the WildFly quickstart demo at
https://github.com/wildfly/quickstart/
• Move your cache to a persistent storage, which means using JPA to store and read
data from the cache (see
Chapter 5
,
Combining Persistence with CDI
, which in-
cludes a JPA-based example of our application)
• Use a distributed data cache such as Infinispan to store data, providing a failover
and data consistency to your cache
Showing all the possible solution implementations would, however, make this section ex-
cessively long; therefore, we will illustrate how to use the last option, which can provide a
good architectural pattern with the least amount of effort.
Turning your cache into a distributed cache
Infinispan is a distributed data grid platform that exposes a JSR-107-compatible cache in-
terface in which you can store data and enhance it by providing additional APIs and fea-
tures (such as transactional cache, data eviction and expiration, asynchronous operations
on the cache, and more). Its primary interface is
javax.cache.Cache
, which is simil-
