Session variables and persisting them to a database_问答_开发者

So there are a few things I know about this topic but I am having a hard time finding where or what to research for this application. I am developing a web app for c# and asp.net web forms and am saving information in session for each user.

I am just wondering when I should timeout session and any information about persisting session to a database so that it can be accessed later. The variables are being changed in session on a frequesnt basis and I do not want it to impact performance to persist these changes in the database each time.

The goal of this is to have variables saved in session for each customer's information as they preform several transactions and pay at the end. If someone walks away for 10 mins and the session times out, I want a way to get that information back to complete the order. I also do not want this to affect performance.

I may also implement a session timeout that triggers a popup screen that will persist these changes to the database only if th开发者_运维问答e user wishes and not each time something changes.

This is my first time dealing with session or caching in a web app and I would like to know more information or where to look or how you would attack this problem.

Thank you.

If the information you're saving in the session is not sensitive, I suggest you store the information in cookies instead. Cookies won't be affected by the session timeout. It also gives you the ability to use the data that you've persisted in another session at a later date.

For example: You could keep track of the items/products that the user views. Next time they visit, you could show them "Recently viewed items". Amazon.com uses cookies for this purpose (and many, many others).

If you really want to store the information in the database OR the information is too much / too sensitive to store in a cookie, you could save it to the DB and then write a cookie with the ID of the record that contains the information. This way, when the user returns to the site, you could look up the previous sessions information in the DB based on the ID in the cookie.

ASP.NET Cookies Overview

The SessionStateStore already saves your session information. When the session times out, then you loose all information related to the user session. Even if you would save the shopping cart contents to your database when the session expires (there is a event for that), you won't be able to tell which shopping cart belonged to the user. You can't even identify the old user when he is returning.

You have two options: a) Make the session timeout longer. b) As James suggested, store the important information into a cookie to be independent of the session store.

If you need to persist some "session" data in a persistent storage like a database I'd think this isn't session data, but other thing.

Reading your question I believe this is some kind of workflow rather than session data.

Session state in ASP.NET hasn't been designed for storing large portions of data; it's more for storing basic values like strings, integers, guids and so on, and using such identifiers (because, for example, SQLServer, StateServer or custom session state modes serialize stored objects and deserialize them whenever these are retrieved again, and obviously complex types have a high impact in performance -, track some kind of user interactions.

Summarizing, I'd not call "performance loss" storing user state or user-related data changes, but using available resources for the right goal.

In conjunction with HTTP cookies, after a session timeout, because cookies would have some kind of identifier(s), your server-side logic should be able of recovering associated data and store it in session state again.

Anyway, if you're worried about performance impact of such solution, you can switch to an n-tier architecture, and, for example:

One machine would have a Windows Communication Foundation-based service implementing the business and data access.
One machine hosting the ASP.NET Web Forms application.

In that case, people browsing your ASP.NET application - the user interface - won't be suffering the side-effects of periodically updating session-related data to some data store, since this would be done in a separate process or machine.