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.
People, here is the issue. We already have a bloated session. Anything and everything is being put on the session.
I have this new requirement where I have to show a drop down in every page of the application. The values of the drop down are populated by a costly database call. I can solve easily by putting the drop down values ( say a hashmap of id-name pairs ) in session and go home happily. However I was thinking of other options and cookies came to my mind.
Having cookies turned on is a requirement in our project so I need not worry about the what-if scenario when cookies get turned off.
Whatever you do, the cookies are just used to identify the user and get the correct session - so whatever you put into the session, the cookie will always look the same. Putting big objects into the session won't have any performance impacts on the application, as long as you don't get memory problems.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Note that cookie values end up being transmitted with every request so they will add to the request processing overhead. There is no reason to be concerned with this unless you actually get memory problems. Bill
Joined: Jul 07, 2004
Thanks folks. Like your suggestions we have decided to go the session route - security hats are a little paranoid of putting such stuff in cookie - and also as William said so far we have had no memory complaints. Also at the same time we are thinking of looking into the stuff we put in session to make sure we dont get memory problems in future.
If this data is common across all users, put it in the Application Scope or even as a static Hash. Putting the same info for all sessions is a huge overhead.
If its specific to a user, thats a different story.
Good luck, Avi
Author and all-around good cowpoke
Joined: Mar 22, 2000
Putting the same info for all sessions is a huge overhead.
That would only be true if each session got a separate copy OR the sessions are being serialized - if the objects are shared in the application then all session references will point to the same set of objects. For objects that have no user specific data, Application scope is the place. Bill [ October 07, 2005: Message edited by: William Brogden ]