Session in database

2

Thinking about the scalability of applications developed in , I looked into alternatives for not using "session in memory".

I saw that it is possible to save the session data to the database and use SQL Server as the state server, but I also saw that there is the ASP.NET State Service, which is a Windows service that exclusively serves to manage the ASP.NET Session Environment.

Which of these alternatives is recommended?

    
asked by anonymous 14.02.2014 / 00:49

1 answer

1

It depends on what your application needs. The question "which alternative is recommended" is very categorical, so I will not answer it directly. I'll tell you a little bit about each model and you should decide which one is most interesting:

  • In process : This is the default, the session is stored within the Application Pool process. If you have only one web server or if the session state is not important (the client being redirected to another server, for example) then this is a good option
  • State server : You use another server to maintain session state. It allows you to have N application servers sharing the same sessions, allowing a client to be routed to different servers between requests without it noticing. However, the session remains in memory. If there is a failure on the server, it will be lost. This risk also occurs in the first model.
  • SQL Server : Sessions are persisted in a table. It allows you to have N application servers sharing the same sessions. As the session is persisted, it will be retained even if the servers fail. However, this option is slower than the State Server, because there is the cost of the database. Also, the sessions are all in a tab, which can be a problem if you have a very high volume of users.

I think that, for you, the most recommended is the state server.

    
14.02.2014 / 01:04