Cache VS Session VS cookies?

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.