Adam Bien's Weblog

HA Without Clustering?

These clustering features are available on most application servers:

  1. HTTPSession replication
  2. Stateful Session Bean replication
  3. Second Level Cache invalidation (e.g. JPA, JDO, previously CMP 2.0) 
  4. Single cluster view of federated / clustered nodes (the administration server)

You should not rely on the first two items in your business logic. The state is mostly replicated asynchronously so your conversational state can get lost. The invalidation of the second level cache is bit more interesting. If JPA entities are changed in one cluster node, a message is asynchronously broadcasted to other nodes, what causes the rejection of the JPA entity from the cache. The replication happens asynchronously again, so you cannot rely on the mechanism to ensure consistency. It only lowers the probability of optimistic locks. Optimistic locking is absolutely needed in distributed (cluster) environments, otherwise the cluster nodes could overwrite the data in the central database. Pessimistic locks are more problematic - and doesn't scale well.

The last item is the most important one. A single point of administration is critical to run clustered environments. You should be able to fire up and kill instances on demand - depending on the load.

So clustering is not necessarily needed for HA. If you would like to run HA applications without a cluster you should consider:

  1. You must not use HTTPSession and Stateful Session Beans as a persistent store. Use them as an optional cache.
  2. Consider optimistic locking as a general strategy early enough. Especially check the presentation logic, whether it can deal with the optimistic lock exceptions.
  3. Use e.g. mod_jk load balancing for spreading evenly the request across the server instances. This is good enough for most applications with a fixed number of nodes.
[See chapter 1 in "Real World Java EE Patterns - Rethinking Best Practices" for more in depth transactions, clustering, state, optimistic concurrency discussion]

NEW workshop: HTML 5 and JavaScript Essentials, Three days in April 2017: from Java EE 7 Architectures over Microservices to Performance, Troubleshooting and Monitoring
On demand workshops: Java EE 7: Bootstrap, Effective, Testing and Microservices available for streaming.


A book about rethinking Java EE Patterns


From a development point of view load-balancing clusters are always a bad thing as you described in your post.

A hot-standby cluster is much easier because there is no replication needed. For sure you will loose session state if the server crashes but it always depends on how many users are affected.

Posted by Simon Martinelli on October 28, 2009 at 03:50 PM CET #


not even hot-standby. You could have multiple, independent instances and spread the load evenly across them. For stateful components it is essential important to setup "sticky sessions" properly.

For HA production you could maintain a parallel "cluster" which is used for test and upgrade purposes. After a successful upgrade and test, you could switch the load to this cluster and then maintain the "hot" one.



Posted by Adam Bien on October 28, 2009 at 05:35 PM CET #

I agree, but then don't forget to to switch off all caches (like JPA 2.0 cache ;-)

Posted by Simon Martinelli on October 28, 2009 at 05:54 PM CET #

Hi Adam,

can you share some updates on how to do high availability JEE apps in light of JEE7 and tackling session stored data

Posted by Ahmed on October 22, 2014 at 03:03 AM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
Online Workshops
...the last 150 posts
...the last 10 comments