Session or No Session?

[Bill Pearce]

All,
I have been building web applicaitons for over two years now, first with ASP and now with Servlets, and wanted to ask for some opinions on the practice of storing information in user session.
When I first started using the session to store information, I found it very convenient. If you were using an object on one page, put it in the user's session, and you could use it again on the next page. Recently though, I have been leaning toward making my web applicaitons session/server independent by storing information in temporary data tables, URL parameters, etc., so that if one server in our pool should fail, the user can continue working when the load balancer sends the next request to another server.
What I am asking for is a few opinions on the use of the session to store applicaiton information. Is anyone else leaning away from using it? Are there those who use it religiously?
Thanks for your input.
Bill

[Thomas Paul]

I never use it because of the problem of using load-balancing servers. There is no guarantee that the user will return to the server where they started in a load balancing environment. My personal preference is to use cookies to store a session identifier (the same way that Session does) but store the actual data for the session in a database.

[Frank Carver]

I think there's some misunderstanding about what a session is. At its minimum, a session is just an id (in a cookie or appended to a URL) which is sent back-and-forth during a sequence of requests and responses. This serves to group the sequence together and allow for context-dependent behaviour from the server.
The Servlet API, in addition to this, provides a Map-based interface to a "session context", where arbitrary Java objects may be placed, to be retrieved by servlets, JSPs etc. which participate in the session. Just because this session context has a Map-based interface, doesn't mean that the session context must be stored in an in-memory map, though. In fact, the Servlet API requires that only Serializable objects be placed in the session, which is expressly so that they can be exported from one server to another, or to a common shared repository such as a database.
How this might be implemented, and how much control you have over the process is up to the author of the servlet container. I use Resin (from www.caucho.com) which, as well as being one of the fastest servlet containers, also allows a very flexible session model. Session context data may be persisted to a database, shared between multiple servers, or "stuck" to one server as appropriate. Load-balancing between multiple servers may be done by the webserver, or by an external hardware solution like a Cisco LocalDirector, and reports on the Resin mailing list indicate that this works very well.
I believe that Orion (www.orionserver.com) can also do this, but I am not faliliar enough with other servers/servlet containers to know if (for example) Tomcat can do it.
The bottom line is that sessions are a very powerful concept, but can introduce extra complexity, so if you really don't need sessions, don't use them.

[Thomas Paul]

The Resin documentation makes it seem that database storage is used only for persistence across JVM failures and not for load balancing. In the case of a request coming into a server other than the one it started with, the request would be routed back to the original server. This, of course, defeats load-balancing.
From the Resin documentation:

Many larger sites like to use multiple web servers with a JVM and a web server on each machine. A router will distribute the load between the machines. A central database handles session state. In this configuration, the site needs to take control of its own sessions. Because the router will distribute the load randomly, any persistent session state needs to be handled by a centralized server like a database.

They then go on to recommend using Resin's own load balancing to increase reliability.
You should note that Cisco LocalDirector is a bad solution to use for session management. It relies on constancy of IP address during a session but there is no way to guarantee constancy of IP addresses during a session. AOL for example will switch IP addresses during a session. It also means that if most of your clients are coming from behind one firewall (in a B2B environment for example with a few large customers) the bulk of your transactions will be routed to a single server and you will lose the load-balancing.
From Cisco's web site:

The current Cisco LocalDirector has a "sticky" feature based on source client IP address, allowing the client to get back to the same real server and IP address throughout a session. This setup ensures that complex transactions such as filling out a form can be completed. Unfortunately, this method of sticky can potentially create problems in environments where proxy servers reside.

I have spent countless hours discussing this issue with vendors from various companies to come up with the appropriate solutions. I have an excellent understanding of sessions and the problems with using them. The fact is that using sessions can work for small applications but can cause major problems migrating that small application to a multiple web server environment. Maintaining state with a session identifier stored in either cookies, encoded URL's, or hidden fields with a database used to store the actual data is the optimum solution.
[This message has been edited by Thomas Paul (edited October 06, 2000).]

[Frank Carver]

Thanks for your detailed information, Thomas. I certainly didn't intend to denigrate your experience, but merely to help casual readers of this and other threads to a better understanding of what sessions are all about. I've seen too many questions from people who assume that all the session data is sent to and from the client, and so always try to discuss things from the ground up.
I bow to your experience of distributed sessions; it's obviously greater than mine.

[Bill Pearce]

Thanks for the input guys. Your comments about migrating a small application to a larger one spanning multiple servers was right on the money, Thomas. That is exactly what I am in the middle of doing right now, and heavy use of the session to store bits of information is complicating things.
I was not aware of such solutions to persist the session data to a database. Thanks for the info.
Bill