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!

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.

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.

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.

First thing you must know! 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, then you should use session.
  
  
• If your client doesn't support cookies, then you can decide to store a cookie inside each request, encoded in the URL (the 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, then 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.

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.

Cookies are stored in browser as a text file format.It is stored limit amount of data.It is only allowing 4kb[4096bytes].It is not holding the multiple variable in cookies.

we can accessing the cookies values in easily.So it is less secure.The setcookie() function must appear BEFORE the tag.

Sessions are stored in server side.It is stored unlimit amount of data.It is holding the multiple variable in sessions. we cannot accessing the cookies values in easily.So it is more secure.

• Cookie is a piece of information shared between co-operating pieces of software, by storing client-specific information on the client's machine and later retrieved to obtain the state information.

• chose the term "cookie" as "a cookie is a well-known computer science term that is used when describing an opaque piece of data held by an intermediary". The term opaque here implies that the content is of interest and relevance only to the server and not the client. The browser will automatically include the cookie in all its subsequent requests to the originating host of the cookie. A cookie has a name and a value, and other attribute such as domain and path, expiration date, version number, and comments. for more

Cookie Version:

Cookie: cookie-name=cookie-value; Comment=text; Domain=domain-name; Path=path-name; Max-Age=seconds; Version=1; Secure

• Server-side session data can store large data and a client-side cookie data are limited in size sent from a website to server, cookies usually contains reference code by this saving data transfer size. Session closes as soon as browser closed, but cookies are exist longer. Browser sends a session ID to the server as a URL param, cookie, or even HTTP headers.

• Cache is a hardware or software component that stores data so future requests for that data can be served faster; the data stored in a cache might be the result of an earlier computation, or the duplicate of data stored elsewhere.

I was always confused between LocalStorage, SessionStorage and Cookie, but not anymore.

Just link the words are self explainable what they suppose to do.

LocalStorage: Local Storage, what does that mean, just thing you don't know anything about technology, but by the itself you can guess. It is some storage which stores data locally.

that what it is.

IT stores data in Browser without any expiration until user clear it through JavaScript code or Clear browser cache.

Session Storage: It seems like it also stores data but related to a session then how different it is from localStorage?

The main difference is your session storage data will be deleted once the session is finish or browser tab is closed or the browser is closed.

You can just try in browser console by setting

localStorage.setItem('name' , 'alex')
sessionStorage.setItem('session','seesion value')

and then close tab and open again, you can still find localStorage data but not sessionStorage data.

Cookie: So this is totally different from the above two. A cookie generally used for the server-side purpose.

• Stores data that has to be sent back to the server with subsequent requests.
• Its expiration varies based on the type and the expiration duration can be set from either server-side or client-side (normally from server-side).
• Cookies are primarily for server-side reading (can also be read on client-side), localStorage and sessionStorage can only be read on client-side.
• Size must be less than 4KB.
• Cookies can be made secure by setting the httpOnly flag as true for that cookie. This prevents client-side access to that cookie