This seems trivial, but I've never had to worry about it before and my Google skills are failing me. How far-reaching is the in-process session bucket for ASP.NET/IIS6, in the sense that you can call Session["whatever"] and get the same value back? Obviously it can't stretch across different servers or application pools (I think). What about different web sites in the same application pool? Can those two see each other's session variables for a user? What about two different virtual directories each with their own web.config?
Thanks!
AFAIK the in-process session has an AppDomain scope, so no, two web applications running in the same pool cannot share an in-process session. Actually the name "in-AppDomain" would be more appropriate.
Obviously it can't stretch across different servers
Sure you can. This MSDN Article has more details.
It can stretch across servers in a farm if the asp.net session is stored in the database.
Perimeter of session is strictly within the one app domain for security reasons
This sounds like you would be better off storing a database value than storing it in a In-Proc session[""]. If you have a state server then the session can be accessed across all machines that use the same state server. In-Proc is just what it says. It's stored In the Process of that single computer.
If you wanted to share Session across applications with a SQL Server backend, there's an article on how to do that.
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.
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 posted the following question concerning ASP.NET web farms.
How to create an ASP.NET web farm?
Guys recommended using Network Load Balancing (NLB) as a primary way of creating a web farm.
However, Wikipedia says that "NLBS is intended for ... stateless applications". Our web application, however, is absolutely "stateful": it is a closed site to which users will have access by login and password, and information for every user will be different: people will see their own trades and operations.
Should we still use NLB in this scenario?
Thank you.
Should we still use NLB in this scenario?
Do not see reasons why not if you follow the guidelines.
The web application is by nature stateless, so even if your users should log-in it does not make the application stateful.
Couple the things which ARE stateful in ASP.NET are:
Session State
Cache
which can be configured appropriately in a WebFarm.
Here is an example on how to configure the NLB.
You can still use a NLB, but you need one that supports Sticky Sessions, meaning that it will always route traffic from a certain client to the same web server. Not the best solution in terms of load balancing, but at least allows you to grow to multiple servers.
I think load balancing is still desirable. You just need to set it up so sessions are "sticky": once a session is open:
http://technet.microsoft.com/en-us/library/bb734910.aspx
Absolutely, yes. There are strategies you can employ to maintain state between servers in your farm. The machineKey settings should be the same for all webservers in your farm so that auth tickets are valid between machines.
http://msdn.microsoft.com/en-us/library/ms998288.aspx#paght000007_webfarmdeploymentconsiderations
There are a few options for managing session state between your webservers:
http://msdn.microsoft.com/en-us/library/z1hkazw7.aspx
http://support.microsoft.com/kb/311209
Is there an elegant solution for synchronizing sessions across multiple ASP.NET applications? I'm sure this could easily be considered a security hole, but there is a 3rd party ASP.NET application involved, for which there is no ability to extend. For this reason, a second [related] site is being developed, but will require direct access to the sessions created on the 3rd party application.
As an example, when a user logs in/out of one site, the same operation should occur on the other site. However, it's important to note that this goes beyond a typical SSO.
Using SQL Server to store is one of your most easy solutions.make sure you have proper permissions set on the SQL objects. I am not familiar with what Manu has suggested. There is actually one more way of doing it which is a little difficult. Its done by implementing a modification of the memento like pattern. App1 stores session info in the database but instead the other application App2 getting access to the DB, the session info is exposed via a service which App2 can reference. Once the user moves on to app2 and is authenticated, its session is restored using the service.
Hope that helps. It worked for me in one of my projects.
Try memcached session state provider: http://www.codeplex.com/memcachedproviders
Since the cache runs in a seperate service, I am pretty sure you can access the same storage pool from different apps.
Cookies are an option assuming the application is storing some key data in its cookies. If the other site is in the same domain, it can read them.
Use NCache - http://www.alachisoft.com/ncache/
It'll help you to acheive what you are looking for.
It has built in distributed ASP.NET session state cache as well, and will help you to share sessions across multiple sites. Details Here