Cache VS Session VS cookies?

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

For example:
I'm using Session variables a lot and sometimes have problems in a booking-application when users start to order products and then go to lunch and come back some hours later and continue the booking. I store the booking in the session until the user confirms or aborts the booking so I don't 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 cache or cookies or some combination for this?

(Also when there is some error in the app, the session-object resets itself and I get more problems because of that)

I'm mostly doing desktop-programming and feel I lack lots of knowledge here so anyone who can expand on where to use Cache, Session, Cookies (or db) would be appreciated

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 unfinished bookings.

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

Have I got it right?

And thanks for great explanations to all of you!

Solution 1:

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.

Solution 2:

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.

Solution 3:

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.