Tomcat 6 has a new clustering implementation compared with that of Tomcat 5.5 and earlier. This book covers the Tomcat 6 clustering implementation. The new configuration enables users to take advantage of plugging in their own message interceptors and to do primary/secondary backup session replication as opposed to the all-to-all session replication that was the only choice in earlier versions of Tomcat.
You may be asking yourself, "What would I need to change in my webapp to make it run as
a distributed webapp?" The good news is it is likely the case that you would not have to
change anything except for adding the
<distributable/> element in your webapp's
WEB-INF/web.xml file. As long as you use session affinity (sticky
session) load balancing, theoretically the webapp does not have to know that any session
replication is going on. But, it depends on what your webapp does. The session is
transparently replicated across the cluster, but not synchronously. So, all of a single
client's requests have to keep going to the same Tomcat instance so that the session's state
data is always seen in a consistent manner until either the session is invalidated or the
Tomcat instance fails. In most cases, the webapp can be used in a nonclustered configuration
(development) and in a clustered (production) configuration, without any changes to the
Before we dig into the details of Tomcat's clustering implementation, here are some specific terms that ...