Introduction

In a J2EE Web application, because HTTP protocol is stateless a J2EE WEB application must maintain the client's state by storing the state in memory's HttpServletSession object. When a balancing target server fails, the HttpServletSession object in this server's memory will disappear, so the client's state (e.g. shopping cart data) will disappear. With the "session recovery"(or "failover) function, the HttpServletSession object in the failed server will be backed up to another balancing target server, so the client's status will NOT disappear.

Many third party application servers such as Tomcat, JBoss, WebLogic, WebSphere have this function. (For more information about this see the section "HTTPSession Failover" of the article "Uncover the hood of J2EE Clustering" from TheServerSide.com.)

Question

Does Interstage support a session fail-over function and if not, why not?

Answer

This was supported in a previous version of App Server. It is not described in App Server V7. However it is still supported but only for legacy applications that run on JDK 1.3 and servlet container V 5.0.1 or earlier. In any case, it was only available on the Solaris version of the Enterprise Edition of App Server.

App Server V8 will ship with this feature.

Why is this so?

Session recovery is basically a marketing feature. In usefulness in real world solutions it is almost zero for the following reasons.

For session fail-over to work, all the Java objects stored in the session must be serializable, so useful things like DB connections or XML cannot be stored.
For performance reasons, both Fujitsu and BEA recommend co-locating applications. This means running both the EJBs and the servlets in the same Java VM. In this scenario, for both Interstage and Weblogic, session recovery cannot be used.

Of course, using the multi-process concurrency of Interstage means that your application will recover significantly quicker than on other application servers.

0 votes so far for this article. Did this article help you?