In the earlier chapters, such as Chapter 2, Working with Dependency Injection, and Chapter 4, Implementing Business Logic, we have seen Singleton and how to use it within a Java virtual machine.
WildFly is able to use the Singleton mechanism even among several nodes of a cluster. WildFly can instantiate Singleton on a node and ensure that it is used within all nodes of the same cluster. This mechanism is called HA Singleton.

Since HA Singleton is physically instantiated on a single node, operations are performed exclusively on that node. If the cluster node breaks or stops, WildFly plans to move Singleton to a nearby node, thereby ensuring high availability of the service.

Infinispan allows Singleton to be replicated on the different nodes of the Cluster and guarantees some transparency to the clients that use it. The client, which can be an EJB, a Servlet, or a mere Java class, knows nothing about Singleton's position. Here, we can see the configuration of the replicable Singleton cache:

<cache-container name="server" aliases="singleton cluster" default-cache="default" module="org.wildfly.clustering.server">
   <transport lock-timeout="60000"/>
   <replicated-cache name="default" mode="SYNC">
      <transaction mode="BATCH"/>
   </replicated-cache>
</cache-container>

As you can see, there is nothing of new respect the other containers. Infinispan is the replication engine, and all replicable instances and services are managed directly by it.

Here, we can see the configuration that guarantees a failover:

<subsystem xmlns="urn:jboss:domain:singleton:1.0">
   <singleton-policies default="default">
      <singleton-policy name="default" cache-container="server">
         <simple-election-policy/>
      </singleton-policy>
   </singleton-policies>
</subsystem>

When a node fails, the simple-election-policy is used to select a new node as Singleton master so that the service is not loose.