Struggling with acceptable use of Session variable in ASP.NET

Question

I tried to wean myself of lopping everything in a Session variable in ASP.NET (I came from a Windows programming background), and I generally completely stopped explicitly storing anything in a Session variable. Can anybody give some guidelines as to what you feel are acceptable uses of session variable?

Here's a specific example...I load a business object from the database and populate and edit screen. The user can edit the values and save. The old way I would load the business object, load my form, and save the business object to a session variable. If the user clicked save, I would retrieve the business object from the session variable, replace the edited values, and then save it. The new way I am loading the business object from the database and load my form. The user would edit the values and click save. I would reload my business object from the database, replace the edited values, and then save it. I'm no web programming expert but I feel the first way is wrong because of the bad stigma of using session variables, and I feel the second way is wrong because it just feels like a crappy way of doing it (loading the business object twice). Let's not take any form of caching into consideration here. How would I handle this?

Answer 1

I'm not at all offended by reloading the business object from the database on the post back to save the users changes.

That object has to come from somewhere on that postback, and the limited overhead associated with a quick DB call like grabbing a specific object is probably your best bet.

Your options for getting that business object back in memory on post back:

• Get it from the DB again. Cons: Some (small) additional DB overhead
• Save it in the user's Session. Cons: Potentially still hitting the database (if session state is stored there) or using a lot of memory (if session state is stored there) and may be storing multiple copies if multiple users may be accessing this object and worst of all, that Session object could be gone with the user hits submit if ASP.NET purged it for whatever reason.
• From the Cache. Cons: Uses some additional memory and you'll still have to go to the DB if the Cache doesn't exist, but I would put big money that any app has many bigger bottle necks to use the Cache on.
• Viewstate. You COULD store the object in the Viewstate (Which sends it to the client, then the client posts it back). Cons: The worst solution, in my opinion. Adding it to the Viewstate means it's going over the wire downstream and upstream and causes the page size to be huge. Session isn't the best, but Viewstate is the devil.

Answer 2

Do you have many users?

Storing your business objects in session might be OK, if your site is low volume.

If you use SQL Server to store your session, then you're effectively loading your business object from the database per post back anyway.

As a rule of thumb though, I tend to use Session to only store information that's applicable to the life of the users session. Business objects that are specific to a single web form, don't really fit this category. For high volume sites, this strategy will probably help you scale better also. It just depends on all the factors concerned.

:)

Answer 3

Reloading an object from the database before update is potentially very dangerous. You can end up missing any possible concurrency violations.

For example if this flow occurs:

1. Display edit screen for Customer 1 on Computer 1
2. Display edit screen for Customer 1 on Computer 2
3. Handle update to Customer 1 from Computer 1
4. Handle update to Customer 1 from Computer 2

It is possible that the (4) should fail because of a concurrency violation, i.e. the update is overwriting changes Computer 2 wasn't aware of. But by reloading from the database, you are ignoring these problems and implementing last update wins.

So for this sort of situation I feel that putting the original entity in the session (or in a hidden field on the form) is absolutely the right thing to do if you care at all about concurrency.

Not to mention lots of people don't like hitting the database again for the extra read...