I want to know in which situation i am use this mode ?
Sql Server Mode is one way to handle sessions inside of a web farm for example. If you were to use in proc session state inside of a web farm, you would not be able to share a session over many boxes. Using Sql Server for the storage of the session means that you can load balance your users over the servers inside of the web farm and the session can be retrieved externally, inside of SQL Server. So one web server would allow you to use in proc session state. With many servers you need to store the session state in a common place so all web servers can see the same one.
It's mainly used when you want to use your app on a web farm, web garden, or cluster. Since page requests can come from multiple processes or computers, you can't use an in-process session state provider.
http://idunno.org/articles/277.aspx
Related
Azure website clarity regarding the instances, are these instances running on multiple machine like a web server farm environment where one client request (session) can be server by different server in the farm.
Issue with server farm asp.net application is that we can loose session variable if that is the case, for this issue to get around we add machine key in web.config that assure client session will always be server by same server so there wont be any lose of session variable.
How does Azure instance work. doesnt it mean we can have 10 websites under same plan let ex s1 Standard.
I am hosting asp.net webform based website on Azure I am confused how exactly instance work. there are lot of article on internet to create confusion.
The thing with PaaS is that you don't have to care about that. If you have a statefull site, you can use the ARR Affinity setting to ensure a client gets always to the same instance:
Adding to Martin Brandl's answer.
An App Service Plan can have multiple instances. These instances run all of the apps in that plan. So it is pretty much like a classic web farm. Except it is way easier to manage.
There is a better way of keeping session information in a web farm rather than relying on sticky sessions with ARR Affinity. Put the session data in a central place. For that you can use Azure Redis Cache or SQL Database. There are ready-made session state providers for these that you can just plug in to an ASP.NET application. That way your session state is not stored on the instances, so you don't need to care if clients hit the same server.
The problem I have with ARR Affinity, is that Azure does not guarantee your instances will remain running. A hardware failure could bring one down and you lose a part of your session data. If you use auto-scale, same thing.
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.
Ok I'm sure this is pretty obvious. But when you say session state is persisted on the "server" in memory, are we talking about IIS or what? When I think of Server-side session State, I think memory in terms of IIS app pools and such. Am I off base or missing anything here?
http://msdn.microsoft.com/en-us/library/75x4ha6s.aspx
the term "server" could mean many things. Sure it's "server-side" but what specific process / memory / area / app on the server are we talking about (IIS only? other?)
I wish MS would have explained what they mean because that's pretty relative.
Specifically this, "store on server"
Storing Data on the Server (in memory)
• Session state
• Application state
• Profile Properties
so "on the server" where in memory and what process/app is handling each of these?
" Sure it's "server-side" but what specific process / memory / area / app on the server are we talking about (IIS only? other?)"
Each site runs in an application pool and each application pool is basically a process on your web server. If your session is configured to be in process, your session objects will be stored in that process' memory
It depends. By default it's in the worker process memory, but it can be on a dedicated state server or in SQL or your own custom provider.
From MSDN:
ASP.NET session state supports several different storage options for session data. Each option is identified by a value in the SessionStateMode enumeration. The following list describes the available session state modes:
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.
Off mode, which disables session state.
ASP.NET is just a framework; it's a collection of classes, and they execute code. It's this code that provides you with session state, and it stores the information about your session state in some objects, just like a dictionary or similar.
(When doing In Proc, then you have state server, sql server, and custom, where custom can be anything as long as someone has written some code implementing the right interfaces)
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.
I have a need to maintain the session state in the database. However I cannot access the database directly from the web server. The web server communicates with an app server which in turn has access to the database.
Is there a way to configure this? Or does a custom component have to be written.
The reason for this setup is to allow for load balancing and to allow the session of a user to be redirected from one server to another.
Use the ASP.NET Session State service, You can run this service directly on your app server - see notes on MSDN here - and configure all your web hosts to store their user session state on that central state server. The ASP.NET Session State service stores sessions in memory on the app server, and doesn't require a SQL Server database.
Note that if you think you need to store sessions in the database because you are using more than one web server, that is not the case: you can use StateServer. That means you enable the session state service on one machine and set up that machine in the web.config of all your web servers so that they all use the same machine for state.
Your only option is to build a custom component.
They really aren't that difficult to do as the only thing you need is for the browser to send you a value from either a cookie or the query string. What's stored is simply name value pairs.
see http://msdn.microsoft.com/en-us/library/aa479034.aspx
You can write a custom SessionState provider.. I think it's the only way.. Have a look on MSDN here.