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.
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.
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 working with an asp.net application that stores most data in a database and not session. I'm wondering of the pros and cons of each and which is the better way to go. For example, you have a pretty busy site and instead of storing user specific variables in session, there is a DB table called user data and it can store all user specific data that can be accessed from any page by querying the database. Which is the better way to go, session or database?
Session (but it depends a lot of the session configuration) :
No database access, or less.
Temporary storage : you may lose the information, at least when the session ends.
Maybe some security issue, depending on where you store the session information
Not shared : you may have issues if you're using a server farm, one server may not have access to the other server session.
May not work if the client disabled the cookies.
Database :
Database traffic for each postback if you need the information on each page.
Permanent storage.
No information stored with the client (cookies...).
Shared : data accessible from any server on a web farm.
Please note that you can store Session information in database. That's why I use the word "may" in the Session part.
See here some session configuration and possibilities
Anything stored in session state will vanish when the AppDomain is reset.
You could avoid that by using an out-of-proc session state handler, but that's no better than a database.
Interesting question. If it's data that's not important across sessions (say, last page viewed) -> session. If it's data that should be persistent (say, password) -> database. The interesting case and the one you probably refer to: Data that should be persistent but is also used often (say, the username). From these, I tend to copy those values from the DB into the session that allow me to work without database access in pages with trivial tasks.
In many cases, I use Session to store temporary data about the... well... "session". In ASP.NET, session is configurable. You can use in-proc (default) which uses the server's memory. You can also configure session to use a database or a session management tool (in case server memory is a problem or you move to a cluster/farm environment).
Session is meant to be temporary. This is great when you are truly storing data about the user who is using your application at that moment. When the user leaves the app and his/her session expires, the memory is freed up. You don't have to manually clear anything out.
Session uses the server's memory. As long as you have enough memory and you're not on a server cluster, this works great. Memory is fast, so getting and setting data in session is very fast and uses zero network bandwidth.
Have said all that, in a few of my apps, I have session configured to use SQL. It's basically the same as using the database directly, but I don't have to deal with DAL... just let the framework work for you.
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.
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.