This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
This has to be a question that arises again and again. I did search a bit but did not find anything pertaining to my situation.
We are designing a session-based application which will use affinity maintaining load-balancing infrastructure. The users are call-center agents - so the typical usage pattern is to initiate a session, spend 4-5 minutes, kill the browser and initiate another session. Every time we have an entity that is session scope (not useful across sessions), we have the choice of placing it in the session object or in a cookie. Which approach is ideal?
LOGIC TO PLACE IN SESSION It is a session scope entity, and should, as such reside in the session object. Since the LB infrasstructure gaurantees session affinity, we should leverage it and save on the network overhead that placing it in the cookie would incur. Cookies have length limits and (potentially) security issues that we can avert by using the container provided Session object. Cookies are more appropriate for information that spans sessions.
LOGIC TO PLACE IN COOKIE Placing more and more data in the Session object make it larger and places a higher load on the server resources. Reducing the session size by placing entities in the Cookie allows the same application to serve more users. This is all the more so true in an application where users come and go at a high rate, while they spend 4-5 minutes in each visit. If the application throws an error for a particular request, the LB infrastructure will redirect the user to another instance. The new instance will have session information from the cookie and can continue seemlessly.
[ May 25, 2005: Message edited by: Sharad Agarwal ]
[ May 25, 2005: Message edited by: Sharad Agarwal ] [ May 25, 2005: Message edited by: Sharad Agarwal ]
Sharad, I think we need to know more about the requirements. What kind of session data is there? In particular, is it useful across sessions. Every time the user closes the browser, he/she loses the session.
So, here is the question. If we know that there is at least some information that we will need to maintain in the Session Object, can there be any justification for placing anything at all in the cookie (aside from the Session ID)? Asked another way, if the server is designed to be stateful, would it make sense to totally avoid using cookies altogether?
Thanks in advance. [ May 26, 2005: Message edited by: Mark Spritzler ]