CODEWITHSUNDEEP
c#asp.net
Matt King
Matt King

Reputation: 749

Session variables vs local variables

Whenever I have to store anything in the session, I have picked up the habit of minimizing the number of times I have to access the session by doing something like this:

private List<SearchResult> searchResults;

private List<JobSearchResult> SearchResults
    {
        get
        {
            return searchResults ?? (searchResults = Session["SearchResults"] as List<SearchResult>);
        }

        set
        {
            searchResults = value;
            Session["SearchResults"] = value;
        }
    }

My reasoning being that if the object is used several times throughout a postback, the object has to be retrieved from the Session less often. However, I have absolutely no idea if this actually helps in terms of performance at all, or is in fact just a waste of time, or perhaps even a bad idea. Does anyone know how computationally expensive constantly pulling an object out of the session would be compared to the above approach? Or if there are any best practices surrounding this?

Upvotes: 8

Views: 1970

Answers (4)

rciq
rciq

Reputation: 1309

I see nothing wrong with your approach. The only drawback is that when some other piece of your (or somebody else's) code changes the session value after your private field has been initialized, your wrapper property will still return the old value. In other words there is no guarantee your property is actually returning the session value except for the first time.

As for performance, I think in case of InProc there is little or no gain. Probably similar to any other dictionary vs variable storage. However it might make a difference when you use other session storage modes. And if you really want to know you can profile your app and find out;) You can even try something as simple as 2 trace writes and some looped session reads/writes between them.

And here's a read on session storage internals: http://www.codeproject.com/KB/session/ASPNETSessionInternals.aspx

Upvotes: 1

Usman Masood
Usman Masood

Reputation: 1967

it surely depends on your Storage Unit but it's a good approach in either case since it's preventing you from DeSerialization if the storage is not InProc... and even in case of InProc it's preventing from Boxing\UnBoxing... so my vote is in favour of your approach.

Upvotes: 1

meir
meir

Reputation: 926

It depends on size of data to be stored, bandwidth (internet or LAN), scale of application. If data size is small, bandwidth is good enough (LAN), scale is worldwide (like Whitehouse.gov), we should store it on client side (as form hidden parameter). In other situations (data size is very large, bandwidth is very low, scale is small (only group of 3-4 people will use the application), then we can store it in server side (session). There are a lot of other factors to consider them in this decision choice. Also I would not recommend you to use only one field in session object. Create something like Dictionary (HashMap in Java) in session, and use it as a storage and user should pass the key of this Dictionary to get this data. It is needed to provide user ability to open your web-site in several tabs.

Example of URL, accessing needed search:

http://www.mysite.com/SearchResult.aspx?search_result=d38e8df908097d46d287f64e67ea6e1a

Upvotes: -2

SirViver
SirViver

Reputation: 2441

Depends on what kind of session storage you are using (for more info, see: here).

If you're using InProc storage, then the performance difference is probably minimal unless you're accessing the object very frequently. However, the local copy doesn't really hurt either way.

Upvotes: 3

Related Questions