Serializable Sessions for Application Server Clusters

  1. Serializable Sessions for Application Server Clusters
    1. Action Plan
    2. References

(This task is not currently assigned to a developer. Please do not work on this yet. )

In general, any objects that need to be stored in the application server session should be serializable. The application server needs session objects to be serializable in order to provide server fail-over by replicating the user's session across a cluster or farm of application servers.

There are two issues that currently limits the Project.net application's scalability and fail-over. One, the Project.net saves too many objects in the user's session. Two, not all session objects are serializable. Over time, the use of Hibernate lazy loading and Spring IoC will help reduce the session memory footprint. However, the main problem is that project.net stores large object graphs in the session for each user. A user's session can be hundreds of MB. This is too large to support clustered fail-over.

Action Plan

  1. Implement the java.io.Serializable interface and explicitly declare a serialVersionUID for all session objects. This is just a tag interface, but the contact is not always that simple. See: http://java.sun.com/j2se/1.5.0/docs/api/java/io/Serializable.html.
  2. The session should be used only to maintain light-weight session objects. The session should not be used as an object cache as it is now. The DAO and persistence layers should provide object cache as needed. A session object such as a project.net Schedule does not need to marshall and unmarshall the entire schedule object graph for serialization. The Schedule session object is sufficient to preserve state. In a fail-over, the Schedule's sub-objects will be lost and need to be reloaded. The Spring service layer and/or DAO layer should handle this automatically.

References