Once your application ships with the distributable stanza in it, the cluster will start, and
provided you have correctly designed your session layer, it will be load balanced and fault
tolerant as well.
You could check it out by pointing the browser to your HTTP proxy. For the default setup,
it would be http://localhost:6666/your_web_application/ .
Programming considerations to achieve HA
In order to support in-memory replication of HTTP session states, all servlets and JSP ses-
sion data must be serializable.
Serialization is the conversion of an object to a series of bytes so that the object can be
easily saved to a persistent storage or streamed across a communication link. The byte
stream can then be deserialized, converting the stream into a replica of the original object.
Additionally, in an HTTP servlet that implements
javax.servlet.http.HttpSession , you need to use the setAttribute
method to change the attributes in a session object. If you set the attributes in a session
object with setAttribute , by default the object and its attributes are replicated using
the Infinispan API. Every time a change is made to an object that is in the session,
setAttribute should be called to update that object across the cluster.
Likewise, you need to use removeAttribute to remove an attribute from a session
Achieving HA in JSF applications
In the applications included in this topic, we have used JSF and the CDI API to manage
the web session. In this case, we transparently replicate the other server nodes to the
beans, which are marked as @SessionScoped .
Clustering JSF-based applications requires special attention if you are dealing with both
HTTP and EJB sessions created by SFSB. In the earlier servlet-centric frameworks, the
usual approach was to store references of Stateful Session Beans in
javax.servlet.http.HttpSession . When dealing with high-level JSF and CDI
Beans, it is vital to provide a @SessionScoped controller to your application, which
Search WWH ::