Is there a way to share session among asp.net balanced applicatiosn without saving session in DB (i.e. without using SQLServer sessionState)? Actually, could load balancers take care of that by themselves?
To share a user session, yes. You have two options:
User an ASP.NET state server and have the web servers point to that.
Enable sticky sessions on the load balancer, so that once a session is started on a particular machine, all further requests for that session will go to the same machine. (really this is the less ideal of the two as it can still have problems if the app pool resets etc.)
There are other applications from MS etc, that you can use to store state also.
Related
We constantly deploy updates to our application
However each deploy terminates all user sessions.
I want to implement a session system that doesnt have this issue using cookies or similar.
What is the best approach?
There are basically four ways of handling session (from MSDN):
InProc mode, which stores session state in memory on the Web server. This is the default.
StateServer mode, which stores session state in a separate process called the ASP.NET state service. This ensures that session state is
preserved if the Web application is restarted and also makes session
state available to multiple Web servers in a Web farm.
SQLServer mode stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is
restarted and also makes session state available to multiple Web
servers in a Web farm.
Custom mode, which enables you to specify a custom storage provider.
You are, most likely, using In Process session (the first one listed) which is causing the session drops during the deployment process.
Moving to any of the others would meet your requirement, but none are instance and they all have upsides and downsides, so you'd need to pick the one that meets your (and your organizations) needs.
I read that when using Session objects in an ASP.NET web app hosted in Azure, if the request is handled by a different (virtual) machine, the app cannot see Session variables of another virtual machine (obviously), so it is recommended to use Azure Caching Service.
Just to understand:
can these 'virtual machine switches' happen in 'normal' web sites too?
I mean: if I don't configure redundancy (i.e. multiple instances) do I have the risk to 'not see' session variables just the same?
Thanks in advance.
AB
If you are using Azure Web Sites with a single instance, then you can technically use in-process session storage since all requests are handled by the same instance. Even when using multiple instances in Azure Web Sites, the default behaviour is to use ARR with "sticky" load-balancing, so that all requests for a particular client are routed to the same instance.
However, there are still times when all in-process session data may be lost. If an instance fails, then the site will be quickly transferred to another instance, and any in-memory (or on-disk) data will be lost. For that reason it is better to use some form of separate, persistent storage such as caching, table storage or a SQL database for your session data if it is in any way essential. I believe all the ASP.NET session providers maintain an in-process cache of the underlying store for performance reasons anyway.
If you are using a Cloud Service to run your site, then all requests are load-balanced between all available instances, so separate session storage is essential.
Greetings,
What do I have to consider when you are coding an ASP .Net website in regards to if the application will run in a environment where there is a load balancer for the IIS?
All user sessions are running by them self with no shared data between sessions. Single connections to MSSQL. Images and files for download will be hosted on one single server.
Windows Server 2008's, C# and .Net 4.0.
The most obvious item is session state. If you are load balancing, multiple requests from the same user may move between servers. The default session provider for ASP.NET (in-proc) doesn't support this (the user would get a new session each time they moved). The easiest solutions are to move to a ASP.NET state server or SQL Server sessions.
FYI: Both of these solutions require that everything that you put into Session be [Serializable]. The in-proc provider doesn't have this requirement, so you may see some runtime errors and need to modify your code when you change providers.
You're going to need to move your session state into the session state service. Avoid keeping objects in session...if you must keep an object in session, make sure it's marked with the Serializable attribute (this is how it is stored, by serialization).
In general, avoid using Sessions. Keep in mind that ASP.Net Session != FormAuthentication. Chances are that your database will be a bottleneck long before the web server, depending on the nature of the application.
I'm storing my user details in the session variable. When some I/O operation happens the other users session also destroying. If I run the same application in the Single server environment the session is working fine.
I have tested with this code also
{meta name='test' content='Set-Cookie: ASPSESSIONID=494351627; path=/' /}
What would be the problem?
Thanks in advance.
Probably the App Pool would be restarting. This could happen every couple of minutes if there is a shared server with several sites sharing an app pool and the app pool is set to recycle if it uses up too much memory.
The only fixes for this are:
a) move onto a different hosting environment
b) use cookies to identify the user and look them up in the database (eg store an encrypted user ID in a cookie and store any related data in the database)
If you have a lot of other stuff in session memory you could consider implementing a database table just for storing session state (in classic asp you would have to roll your own - in .net this is a standard config option).
If it is a big app with a lot of reliance of session variables you would want to go for option A if possible.
We have 5 balanced web servers with various websites.
What I am trying to achieve is to ensure a single login.
i.e. the same user account cannot login to the same website more than once at any given time.
The method i'm considering for solving this, is to share session amongst the servers so I can control which session is assigned to which account. I can then have control over my logins. If a user logs in and there is already a session assigned to their user account, I can just expire the first session or reject the login.
I don't want to lose the benefit of the balanced servers, so using a single Sql Server as my session state server, or a single server to handle login is not an option.
Is distributed session (something like Scaleout Sofware) the correct approach to achieve this?
Or is there another mechanism to handle single login that i'm blissfully unaware of?
You have two set of problems here:
1) Allowing just one connected user in a web farm scenario
2) Detecting user logoff
To solve the first the only solution is a central storage for some kind of user state, using a central server to store the ASP.Net session or some other kind of centralized user state. This central storage can be SQL Server using the native management of session state (btw also Oracle, from Oracle 11, can support session storage), the AspState service or an external solution, like ScaleOut (as you said) or its open source alternative memcached (see https://sourceforge.net/projects/memcacheddotnet/). Or you can design a simple centralized web service that check active logins against a SQL Server database, this way you can also quickly create reporting tools about logged on users and so on.
Real problem, in my opinion, lies in the second part, that you need to maintain the different "wrong logoff" scenarios that are available in a web world (like closing the browser due to a crash or shutting down applications without logging off), giving you application some way to gracefully work with user that has an old session enabled (as you said simply expiring the first session can work).
Keep also in mind that using a state server like SQL server will not make you loose the balanced servers, if's the way of working to have a web farm environmet and sharing session, only problem lies in performance (if session state become large) and the cost involved in using SQL Server if you do not already have the proper license.