views:

656

answers:

2

We are currently using database to maintain state information (in a separate table) for the user. We fetch that information from the database every time user access the application (sends request) and update it in the database back after processing the request.

This has worked very well for us in many of our projects and is very easy to implement but this adds an overhead to call the database and save state information.

Are there any other ways available that would work better in this case?

+2  A: 

Out-of-the-box, MS offers a StateServer mode. This lets you store Session data in memory on a single server shared by one or more Web servers. In some cases (if your session state SQL Server is under significant load), this may give you a boost.

By default, the SQL Server session provider fetches and saves session items per item. If you know your session use and this seems inefficient (you fetch and save several items per request), you could implement a custom SessionState Store Provider on SQL Server that fetches all Session items at the beginning of the request and saves them all at the end of the request.

Other resources:

Corbin March
A: 

There are number of strategies. I hope that your session is sticky (i.e. routed to the same machine all the time it is up). In this case, you can cache data locally (in memory) and use DB only for backup ("write-only"). Moreover, there are solutions like memcached providing distributed cache.

Dmitry Khalatov