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.
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.
From the Resin documentation:
They then go on to recommend using Resin's own load balancing to increase reliability.
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.
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).]
I bow to your experience of distributed sessions; it's obviously greater than mine.
I was not aware of such solutions to persist the session data to a database. Thanks for the info.