In Chapter 3, Beginning Java EE 6 – EJBs, we have shown our Ticket System example, which was built around the following:

Let's see how to apply the necessary changes to move our application in a cluster context.

So let's start from our stateful EJB:

@Stateful
@Remote(TheatreBooker.class) 
@Clustered
public class TheatreBookerBean implements TheatreBooker {
  private static final Logger logger =
      Logger.getLogger(TheatreBookerBean.class);

  int money;
  @EJB TheatreBox theatreBox;

  @PostConstruct
  public void createCustomer() {
    this.money=100;
  }



  public String bookSeat(int seatId) throws SeatBookedException,NotEnoughMoneyException {
     // Unchanged method
  }
 } 

As you can see, the only relevant change to our stateful EJB is the @org.jboss.ejb3.annotation.Clustered annotation, which is added at the class level. We can also apply this annotation in the stateless EJB, which will add load-balancing capabilities to your business methods, there by improving its scalability:

@Clustered
@Stateless
@Remote(TheatreInfo.class) 
public class  TheatreInfoBean implements TheatreInfo  {
@EJB TheatreBox box;

@Override
public StringBuffer printSeatList() {
// Unchanged method

}


}

As it is, our Ticket application is ready to be deployed in a cluster; however, there's a last pitfall. As a matter of fact, the singleton EJB used to hold the cache of 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 a new one (unsynchronized) will be used.

There are several alternatives to set up a cache in a clustered environment:

Showing all possible solution implementations would, however, make this section excessively long; therefore, we will illustrate how to pursue the last option, which can provide a good architectural pattern with the least amount of effort.

Infinispan is a distributed data grid platform that exposes a JSR-107-compatible cache interface in which you can store data and enhance it by providing additional APIs and features (such as transactional cache, data eviction and expiration, asynchronous operations on the cache, and more). Its primary interface is javax.cache.Cache, which is similar to the Java SE java.util.ConcurrentMap, with some modifications for distributed environments. In particular, it adds the ability to register, deregister, and list event listeners, and it defines a CacheLoader interface for loading/storing cached data. Cache instances can be retrieved using an appropriate CacheManager, which represents a collection of caches.

So here's our singleton TheatreBox class rewritten using the Infinispan API:

@Singleton
@Startup
public class TheatreBox {
  @Resource(lookup="java:jboss/infinispan/container/cluster")
  private org.infinispan.manager.CacheContainer container; 
  private org.infinispan.Cache<Integer, Seat> cache; 
  private static final Logger logger =
      Logger.getLogger(TheatreBox.class);
  @PostConstruct  public void start() { 
     try {
         cache = container.getCache();
         logger.info("Got Infinispan cache");
            setupTheatre();
        } catch ( Exception e) {
              logger.info("Error! "+e.getMessage());
         
         
        }
      
      }   
  public void setupTheatre(){
     
    int id = 0;
    for (int i=0;i<5;i++) {
      int cacheid=++id;
      Seat seat = new Seat(cacheid,"Stalls",40);
      cache.put(new Integer(cacheid), seat);
    }
    for (int i=0;i<5;i++) {
      int cacheid=++id;
      Seat seat = new Seat(cacheid,"Circle",20);
      cache.put(new Integer(cacheid), seat);
    }
    for (int i=0;i<5;i++) {
      int cacheid=++id;
      Seat seat = new Seat(cacheid,"Balcony",10);
      cache.put(new Integer(cacheid), seat);
    }
    logger.info("Seat Map constructed.");
     
  }
  public List<Seat> getSeatList() {
    List<Seat> dataList = new ArrayList<Seat>();
    dataList.addAll(cache.values());
    return dataList;
  }
    
  public Seat getSeat(int seatId) {
    return cache.get(seatId);
  }
   
  public void buyTicket(int seatId )     {
    Seat seat = cache.get(seatId);
    seat.setBooked(true);
    cache.put(seatId,seat); 
  }
}

public Seat getSeat(int seatId) {

   return cache.get(seatId);
}


public void buyTicket(int seatId )     {

   Seat seat = cache.get(seatId);
   seat.setBooked(true);
   cache.put(seatId,seat); 

}

}

The first thing we want to stress is the @Resource annotation, which injects a org.infinispan.manager.CacheContainer instance; when the JBoss AS deployer encounters this annotation, your application will include a dependency on the requested cache container. Consequently, the cache container will automatically start deploying and stop (including all caches) undeploying of your application.

Subsequently, when the EJB is instantiated (see the method start, which is annotated as @PostConstruct), org.infinispan.Cache is created using CacheContainer as a factory. This cache will be used to store our highly available set of data.

The operations performed against the distributed cache are quite intuitive: the put method is used to store instances of the Seat object in the cache and the corresponding get method is used to retrieve elements from it, just what you would do from an ordinary hashtable.

As far as application deployment is concerned, you need to state a dependency to the Infinispan API explicitly, which is not included as an implicit dependency in the AS 7 class loading policy. This is most easily done by adding the following line to your application's META-INF/MANIFEST.MF:

Dependencies: org.infinispan export 

The remote EJB client will not need any particular change in order to be able to achieve high availability. We have added a pressAKey method between each ticket transaction so that you will be able to shut down the application server that is pinned to our EJB client, and thus test failover on the other server node:

private static void testRemoteEJB() throws NamingException {  
  
    
    final TheatreInfo theatreInfo = lookupTheatreInfoEJB();   
    final TheatreBooker theatreBook = lookupTheatreBookerEJB();

    try {
      String retVal = theatreBook.bookSeat(5);
      logger.info(retVal);
      logger.info(theatreInfo.printSeatList().toString());                
    } 

    catch ( Exception e) {
      logger.info(e.getMessage());
    } 
    logger.info("Press [Enter] to continue");
      // Await for key press. Not included for brevity
    pressAKey();

    try {
      String retVal = theatreBook.bookSeat(7);
      logger.info(retVal);
      logger.info(theatreInfo.printSeatList().toString());                
    } 

    catch ( Exception e) {
      logger.info(e.getMessage());
    } 
}

Now that we are done with the client, our last effort would be deploying a jboss-ejb-client.properties file, which will contain the list of servers that will be initially contacted (via remoting) by our client application:

remote.connectionprovider.create.options.org.xnio.Options.SSL_ENABLED=false
remote.connections=node1,node2
remote.connection.node1.host=localhost
remote.connection.node1.port = 4447
remote.connection.node1.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

remote.connection.node2.host=localhost
remote.connection.node2.port = 4647
remote.connection.node2.connect.options.org.xnio.Options.SASL_POLICY_NOANONYMOUS=false

As you can see from this file, we assume that you are running a two-node cluster on the localhost address, the first one running the default port settings and the second one using an offset of 200 (just as shown in the second paragraph of the Starting a cluster of standalone nodes section).

Replace the remote.connection.nodeX.host variable value with the actual IP or host if you are running your server nodes on different machines from your client.

Deploying an application to a cluster can be achieved in several ways; if you prefer automation instead of copying each archive into the deployments folder, you can re-use the CLI deployment script contained in the earlier chapter.

Alternatively, if you are using JBoss'Maven plugin to deploy, you can parameterize its configuration, including the hostname and the port as variables, which will be passed to the command line:

<plugin>
      <groupId>org.jboss.as.plugins</groupId>
      <artifactId>jboss-as-maven-plugin</artifactId>
      <version>${version.org.jboss.as.plugins.maven.plugin}</version>
      <configuration>
          <filename>${project.build.finalName}.jar</filename>
          <hostname>${hostname}</hostname>
          <port>${port}</port> 
      </configuration>
</plugin>

Therefore, you will use the following shell to compile the package and deploy the application on the first node:

mvn install jboss-as:deploy –Dhostname=localhost –Dport=9999

For the second node, you will use the following:

mvn install jboss-as:deploy –Dhostname=localhost –Dport=10199

Once you have deployed both applications on your server node, you should be able to see the cluster view in the server console logs, and also see that the Infinispan cache has been started. The following is the expected log for the first node:

The following is the corresponding log for the second node, which is bound to the same server address (localhost) with a port offset of 200:

Before launching your application, update Maven's exec plugin information, which should now reference our remote EJB client application, as shown in the highlighted section of the following code snippet:

<plugin>
   <groupId>org.codehaus.mojo</groupId>
   <artifactId>exec-maven-plugin</artifactId>
   <version>${version.exec.plugin}</version>
   <executions>
     <execution>
         <goals>
            <goal>exec</goal>
         </goals>
     </execution>
   </executions>
   <configuration>
     <executable>java</executable>
     <workingDirectory>${project.build.directory}/exec-working-directory</workingDirectory>
     <arguments>
       <argument>-classpath</argument>
       <classpath>
       </classpath>
       <argument>com.packtpub.as7development.chapter10.client.RemoteEJBClient</argument>
     </arguments>
   </configuration>
</plugin>

You can run it using the following command:

mvn exec:exec

The first part of the client will show the evidence that we have successfully completed the first transaction. On the client console, you will see the return value from the booking transaction and the Seat list:

The following screenshot shows the server node where our EJB client landed:

Now shut down the preceding server node (Ctrl + C would suffice if you are starting it as a foreground process), and press Enter (or Return in Mac) on the client application.

As you can see from the following screenshot, you should see that the session continues to run on the survivor node and correctly displays the session values (the money left). Your client window should also display the updated cache information.