Cache VS Session VS cookies?

Question

What are the do's and don'ts about Cache VS Session VS Cookies?

For example: Im using Session variables a lot and have sometimes problem in a booking-application when users starts to order products and then goes to lunch and come back some hours later and continue the booking. I store the booking in the session until the user confirm or abort the booking so I dont need to talk to the database and handle halfway bookings in the database when users just click the X in the browser and never comes back.

Should I instead use cashe or cookies or any combination of all above for this?

(I have also had problems as when there are some error in the app the sessison-object resets itself and I got a lots of more problems because of that)

Im mostly doing desktop-programming and feel I lack a lots of knowledge here so anyone who can expand on where to use Cache, Session, cookies (or db)

Edit: From the answers it seems that a combination of DB and cookies is what I want.

1. I have to store the booking in the database connected to a session-id
2. store the session-id in a cookie (encrypted).
3. Every page load checking the cookie and fetch the booking from the database
4. I have a clean-up procedure that runs once a week that clears unfinnished bookings.

I cant store the booking as a cookie because then the user can change prices and other sensitive data and I had to validate everything (cant trust the data).

Have I got it right?

And thanks for great explanations to all of you!

Answer 1

Session is stored on the server will time out by default in 20 minutes (This is adjustable). I would store this in a cookie, or in viewstate(if available) to prevent the timeout.

If your state is stored InProc(the default setup), then having more than one server in a farm is going to cause you issues also unless you have implemented some sort of "sticky session" that will keep the user on the same server in the farm for subsequent calls.

I try to avoid session when possible(puts extra load and memory usage on the server), and keep viewstate turned off when possible to keep the page size low. Cookies are often the most lightweight option, but your users might have this turned off and you will need a fallback mode that still allows them to use the site.

Edit (adding clarification based on response from asker):

Viewstate is stored in a hidden field, and is a serialized representation of all objects in Viewstate storage. Viewstate is automatically used to store the page's state, but you can explicitly add and retrieve your own objects to and from Viewstate programatically if you choose to.

So yes, datasets can be stored in Viewstate.

Answer 2

State management is a critical thing to master when coming to Web world from a desktop application perspective.

• Session is used to store per-user information for the current Web session on the server. It supports using a database server as the back-end store.
• Cookie should be used to store per-user information for the current Web session or persistent information on the client, therefore client has control over the contents of a cookie.
• Cache object is shared between users in a single application. Its primary purpose is to cache data from a data store and should not be used as a primary storage. It supports automatic invalidation features.
• Application object is shared between users to store application-wide state and should be used accordingly.

If your application is used by a number of unauthenticated users, I suggest you store the data in a cookie. If it requires authentication, you can either store the data in the DB manually or use ASP.NET profile management features.

Answer 3

Web is by nature disconnected model and none of the options mentioned (Session, Application, Cache, ...) are reliable enough. Session will timeout, worker process recycles, etc.

If you really need to store the users progress, reliably and through extended periods, the database is your only solution. If you have users profile (if the user must log in), then it's straightforward. If not, generate a unique Id, store it in the cookie (or URL) and track the user based on that identification.

Just make sure the Id is encrypted and then base64 encoded string and not just a numeric value.

EDIT:

After your additional explanation in the original question and comment from Mehrdad Afshari, good solution for you would be to use Session but set the storage to Sql Server instead of InProc.

Here's more details and instructions how to set it up: http://msdn.microsoft.com/en-us/library/ms178586.aspx

Have in mind that you will STILL have the session timeouts, but they will survive application pool recycles, even server restarts.

If you truly need a permanent storage, custom solution with the database, as I originally outlined is the only solution.

Answer 4

You should not use the Cache-object to cache session data, for the cache is shared between all users. Instead you could use Asp.Net Profile properties to store your data or you could add an event handler to the Session_End event and store the data if the user leaves the computer for too long.

Answer 5

First cookies are used by session : the server knows who is your user thanks to the cookie which is exchanged between the client and server every request (this works with HTTP headers set-cookie and cookie).

The real question is : If you want to store user information during the navigation USE session. If you client don't support cookies, you can decide to store cookie inside each request, encoded in the URL (server will use the URL instead of the cookie to find the right session for the request).

Then consider where you want to store your session : if your site must have high disponibility and high performance, you must not store session inside the process but inside a database. This way you will be able to share the work among several web server. But you will loose in simplicity (because objects you store in your session must be serializable), and you have one more round trip between your webserver and your database server.