High availability is the ability of a system to continue functioning after the failure of one or more of the servers. You can achieve high availability of the MDM Hub either with multiple standalone application server instances or with application server clusters.
The application servers cannot make the MDM Hub highly available because the MDM Hub uses stateless session beans. The stateless session beans do not maintain a conversational state with clients, and therefore application servers cannot synchronize the state of the beans across the application server cluster nodes.
To achieve high availability, the MDM Hub uses an internal metadata cache mechanism. The metadata caching mechanism synchronizes the metadata in the MDM Hub environment and makes it available across the MDM Hub implementation. If an application on one machine fails, the metadata is available in the cache for the applications that are online. The metadata caching mechanism uses Infinispan, which is a replicated cache that can handle metadata caching requirements in any application server environment.
Consider the following contexts that impact your decision in favor of a highly available environment:
If the MDM Hub implementation contains multiple Hub Server instances, during a failure, the Hub Console operations do not fail over to an active node. To ensure that the Hub Console operations fail over to an active node, the Hub Server instances must be part of an application server cluster.
If a batch job request is through the Hub Console, the request fails over to the active nodes in the cluster. If a batch job request is through a Services Integration Framework API, the request does not fail over to the active nodes in the cluster. The batch jobs do not fail over because the batch jobs do not replicate.
If the MDM Hub implementation contains multiple Hub Server instances and you use JMS messages, you can deploy the Hub Server instances in a cluster. If you do not deploy the Hub Server instances in a cluster, the outbound JMS messages are not available to all consumers. Also, you can consider managing this scenario by using an appropriate JMS server deployment strategy.
If you use Informatica Data Director (IDD), the IDD session binds to the application server node that services the session. If the application server node fails, the IDD session ends. The IDD session does not replicate. The IDD user needs to log in again.