Hello,
The code needed for HTTPSession clustering is now in CVS. Nevertheless, as
the clustering build environment is not functional, I haven't been able to
perform full testing.
The more I was coding, the more I was convinced that this solution (entity
beans) is really great! :)
Here are the parts involved (from bottom to top):
- A new persistent store, CMPClusteredInMemoryPersistentManager, based on
the DistributedState (DS) service, provides cluster-wide in-memory
replicated persistence
- A new cache, ClusterSyncEntityInstanceCache, extends EntityInstanceCache
and listen to the DS for remote modifications on beans. If such a
modification occurs, the bean (if in) is removed from the local cache. This
provides a distributed cache management.
- an Entity bean, in org.jboss.ha.httpsession (.interfaces .ejb),
provides a simple way to store HttpSession. More on this below.
- To wrap all this, a JMX Service, ClusteredHTTPSessionService (in
org.jboss.ha.httpsession.server) provides the primitives that will be used
by the servlet container: ~getSession, setSession, removeSession.
Furthermore, it will also cluster-wide-clean sessions that timeout.
Now, some more detailed information.
HAPartition
===
In the current implementation, the persistent store and cache always use the
default partition. This is not difficult to change programatically but I
haven't took time to consider a clean solution to do it at configuration
time.
Entity Bean
===
On the entity bean interface, the getSession and setSession use an interface
that extends javax.servlet.http.HttpSession. Nevertheless, inside the bean,
the actual session is stored in a MarshalledObject. Thus, the session, when
received on a node, is only unmarshalled if really needed (lazy
unmarshalling). This is used, for example, in the cleaning of timeout
sessions for example (more on this below). The MarshalledObject class will
need to be replaced later by something that makes resulting marshalling
smaller. The bean also contain the last access and creation times as
independant fields (more on this below)
Session timeout
===
This is a dummy implementation. The JMX service will frequently (every 30
seconds), check if sessions have timeout. For this, it will make a
home.findAll() and, for each bean, check if its lastAccessTime is old enough
(life duration can be modified through the JMX service) for the bean to be
removed. This explain why the session is stored in a MarshalledObject and
that the last access and creation times exist as independant fields: the
service is able to determine which sessions to remove *without* having to
unmarshall *all* beans every 30 seconds...
Servlet container implications
==
As we exchange an HttpSession object between the servlet container and the
EJB, it needs to be Serializable. Consequently, a new interface has been
defined:
public interface SerializableHttpSession
extends javax.servlet.http.HttpSession,
java.io.Serializable
{
public boolean areAttributesModified (SerializableHttpSession
previousVersion);
}
This interface makes sure we have a HttpSession compatible interface that is
Serializable. Furthermore, a method has been introduce that ask the
HttpSession to decide when 2 sessions are differents. As indicated in the
Javadoc, this method should *not* check all data (such as the last access
time). This in order to reduce the cluster communication (more on this in
the JavaDoc comments of the JMX Service)
The Servlet container must provide a compatible implementation, call
getSession when a new request comes in and setSession after the request has
been performed. All the rest is managed by the service, bean, persistent
store, ...
Caching
===
Thanks to the distributed cache mechanism, if you use a front-end
load-balancers that support sticky sessions, all requests of the same
session will be targeted at the same node. Consequently, the
jmxservice.getSession() call will a return a session that is still in cache
and the overhead will be very small. This is good news. The servlet
container, should not try to handle caching of session itself for a good
reason: it can't. It doesn't have sufficient cluster knowledge to be sure
that he owns the last version of the session.
That's all for today. If I've missed some details, just ask!
Cheers,
Sacha
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
