In many application server environments, for reasons of load balancing and failover, there is more than one JVM process sitting behind a web server. A web server plugin usually, but not always, handles the job of deciding which Java "engine" will handle a given request (sometimes a dedicated process does this instead).
Because HttpSessions usually exist in the context of a single Java process, many application servers either allow you to (iPlanet) or force you to (WebLogic) run in "sticky" or "pinned" mode, meaning a given browser session will only be load balanced for its first request; subsequent servlet requests within the same session will always be routed to the same Java engine, to ensure the same HttpSession is available.
The proposed final draft of the servlet 2.3 specification indicates that a container may provide a facility for distributing the HttpSession, at the vendor's discretion, but it's certainly not a requirement.
I believe iPlanet lets you do this, if you want, by having one of its engines maintain the distributed session information. You can designate one or more backups, with each backup also maintaining this set of sessions. Performance naturally gets worse with each additional backup. However, I have heard some people say that they've had better performance ignoring this feature and just using the simpler "sticky" session solution.
WebLogic does offer a session "in-memory replication" feature, but it seems to me to be more for failover purposes... from my reading of the documentation, it seems you don't have a choice on the sticky issue... you have to use it; an HttpSession on one Java engine is not available in the others. The copies of the sessions seem to exist only to protect against losing session iformation when a JVM dies.
Websphere looks like it's taken an in-between position: you can use the sticky behavior, or configure something they call "Session Persistence", where sessions are available from all engines, but this is achieved by storing them in a database. Some Websphere performance presentations I have seen claim this is a quite slow.
On the freebie side, Apache Tomcat has a notion of multiple Java engines ("Tomcat Workers"). However, the HttpSession isn't distributed and I don't see any provision for doing anything other than using the sticky option.
I wonder if a bolt-on, all-Java implementation of a distributed session would be useful. iPlanet wouldn't be improved by it, and someone might argue "just use stateful session beans" in the other EJB containers, but I still wonder if it would be a fun exercise and useful for Tomcat users (no EJBs there) and others. Something where you tell the system about the other JVMs via a properties file (things like host and port numbers), and the developer just uses a setAttribute()-type method call to write. Probably dog-slow with all the network traffic and serialization/deserialization in a large environment; I don't know.
One problem I see is in the cases where the vendor forces a sticky behavior (WebLogic? Tomcat?). Even if you had a distributed session service, it wouldn't matter if some load balancing logic is forcing subsequent requests to the same Java engine for the duration of an HttpSession. Well, I suppose this wouldn't happen if you are never using HttpSession.getSession() in the first place, but a replacement instead.
Are people pretty happy with the sticky session idea? Can anyone comment if it seems to perform much better than iPlanet's distributed session alternative? Or IBM's Session Persistence via the database? Would it be at all useful to add such a facility? I suspect it would be slow in pure Java (which I'd want to use, to be portable), and this slowness would negate anything you'd gain by "not going sticky." But it would be fun to play with. Any thoughts on this, or knowledge of anything already available?