<< Cool ScriptManager stuff I missed... | Home | A Question you should ask when hiring a non-entry level developer >>

To Cache, To Static, or To Session "When?" is the question

DonXML has an interesting article over here that got me thinking about a technique I have been using for years now, and I’m not sure I’ve seen much written about it.

The basic tenet begins like this: I avoid session like the plague (not sure why except I have visions of some abuses I have seen... like full DataTable’s stored in session). The only time and I mean the ONLY TIME I use Session is if I have a value that needs to be associated with a user across the WHOLE site. As a result I really try to design my model where there are minimal values that need to be associated with a user site-wide.

What I have seen is that values come in 3 basic variations as far as Web site variables go: Values associated with a user everywhere, values associated with a user necessary for a few pages, values that really are application level values.

My suspicion about "Values associated with a user everywhere" is that they are not as prevalent and are often the result of programmers either not fully understanding web apps, they just aren’t thinking things through, or they are pushing a value into session site-wide when they only need it in a couple places. Treat Session like you do ViewState: it is a snake (maybe a poisonous one) that while necessary to kill the rats in your back yard due to the citrus trees, you don’t want a dozen snakes in the backyard either... Only use the number of snakes that you need (if you have no rats then 0 is the perfect number of snakes). So the lesson here is to really look at your user-related values: determine if they really are used everywhere, and determine if they need to be available in memory the whole the user is on the site.

For values associated with a user necessary for the a few pages, I tend to use cache, or I do use Session (but I clean up immediately after I’m done). When I use Cache I factor in the user’s Session ID. The thing I like about Cache is that I have a much richer set of expiration options. Session sticks while a user is clicking around the site... Cache let’s me absolutely set an expiration time. I also am aware of the fact that Cache can be unloaded early (so I use Cache as a temporary place for a value knowing that I may need to retrieve it again). If it’s something that isn’t stored elsewhere then into Session it goes (even if I have to delete that Session var later). It’s really about managing the data in memory.

For the application type values, I usually forget about the whole Application mechanisms (you might use them, but I do something else), I like to use static/shared values on individual classes. This has the effect of better organizing your code (and if you do any else with the class it simplifies things... I suspect some automated test guys would agree with me on this point). Why mention these here? Well I have seen my share of things that were really application related or indexed application related (such as storing this customer’s company info in session... that really should be either a cache or a static, and it should be retrievable by some company id).

Don’s post was originally spawned by the new Velocity cache from MS. Honestly the only comment I have on it is that I wish they had chosen a different name. I hear Velocity and I think about the text template engine (the one for Java... but the one for .NET is nvelocity)

Print | posted on Tuesday, June 10, 2008 11:15 AM

Feedback

# re: To Cache, To Static, or To Session "When?" is the question

left by Jonas Stawski at 6/10/2008 12:41 PM Gravatar
Jay,
I am like you. I try to stay away from Session as much as possible, but sometimes it's handy. When I do use session I generally use it to store a User object which holds all the information related to the logged in user. I then add a LoggedInUser property to the base page which is available to all my pages. Since I use this on every page and the odds of the user info changing are very low I store the object in a session variable. I also check whether the session is null and retrieve it again if it has become null for some reason. I really try to stay away from session for passing info back and forth between pages. Doing so can become very dangerous as it is very easy to loose control of where the variables are set or retrieved. As well as checking for null references and types can add a lot of code (nothing wrong with that, but it makes it look dirty).
One thing I do not agree with you is using the cache object to store information for sessions. I like the flexibility the cache object gives you, but the cache object is inteded for application level and even though you can be very careful to remove the cache you still have the posibility to forget to remove it and have a huge problem by retrieving other user's information that were stored in cached from a previous session. I use the cache to store application level information such as a List<State> or other types of information that doesn't change very often. One of the things I do is set an expiration date to all my cache objects. The date depends on how often the data can change. The List<State> will most likely not change at all so I give it something like 3 weeks. I add a helper class with static/shared methods to retrieve from cache. Something like GetStates. The method checks whether the List is cached and if it is it retrieves it from cache, otherwise it gets it from the DB and adds it to the cache. One of the biggest errors developers do sometimes is to beleive the object in cache/session/viewstate will always be there and don't check for null references. Anyway, just my 2 cents on the matter.

# re: To Cache, To Static, or To Session "When?" is the question

left by Jay Kimble at 6/10/2008 12:46 PM Gravatar
We're in agreement... I was struggling with how to discuss and what I do with those fringe cases where I have value "here" and the user is going over "there" and the value is specific to this user and isn't saved yet (and can't be)...
Title  
Name
Email (never displayed)
Url
Comments   
Please add 5 and 7 and type the answer here:
Copyright © Jay Kimble