I've implemented a custom session state provider for Oracle in my application. It seems to run smoothly (without errors!), but I'm having trouble retrieving some Session variables when I redirect to another page. But it doesn't happen all the time.
When the Session starts, I load a User object into Session. It stays there, because when the user gets to the starting page (and is authenticated), the app still recognizes him. It has no problem retrieving the User object from Session.
But if I pass a value into Session on one of my pages inside the app, then redirect to another page in order to utilize that Session variable, the new page retrieves null from the same named Session variable. Using the Visual Studio Watch window, I can actually see its value change from "100" (or whatever) to null. I don't get it.
The session provider seems to be working correctly because as I said, I'm able to persist some variables. Does someone know what the reason might be for Session to "lose" a value? Thanks.
If you are doing a response.redirect in the page, that can cause the thread to abort before the Session is written back to the database.
Related
Is it normal for some variables not to have been reset and still retain their value
after a page transaction,
and also even after browser was closed but immediately re-opened and same web page re-browsed?
In my VB ASP.NET web app, user performs several steps.
I discovered a bug where after final step, if user refreshes page a couple times,
then closes browser (IE11),
then opens new browser and goes to site,
when Page_load() is called visual basic variables are sometimes not reset, and still have previous value from when page was previously browsed.
It depends on where the state for that variable is tracked.
If the variable is scoped locally to a method, then no it won't still be the same. Once the method is finished, the value is lost.
If the variable is an instance value on an object, it will be retained as long as that object is in memory. Once the object is disposed (usually when no variable references it anymore), the value is lost.
If the variable is static (Shared in VB) then it's scoped to the app domain. It will continue to hold its value as long as the application is running. Once the application exits, the value is lost.
If the variable is kept in session then it will retain its value until the session is ended (either in code, usually by the user logging out, or by the application exiting). Once the session is ended, the value is lost.
If the variable is populated from a cookie then it exists on the client machine and will be supplied to the application any time that client accesses the application. Cookie expiration can be set when creating the cookie, and once it expires the value is lost.
If the variable is populated from some external persistence (such as a database) then it will retain its value until that persistence is changed. The application can shut down, start again, even run on a different machine and the persistence still holds the value.
Look at your variable and determine its scope, that will tell you when it will lose its value.
We are using Session to save user specific information between requests and are now in the process of converting to an out of proc state server for load balancing. My problem is I do a lot of one time setup for each unique user in Session Start. With out of proc session state Session Start does not get fired for an existing user. For example if the web server gets cycled the app receives a BeginRequest but no SessionStart, however I still need to do some configuration with the newly restored session so need a way to know when it has been restored and can be accessed.
Any suggestions?
Found the answer here Session State Not Available In This Context - In Global.asax
Application_AcquireRequestState()
Sorry for the question, should have read more carefully.
The above simplifies my situation, but highlights my dilemma -- occasionally my users are unable to access their session variables (well before the session timeout). My configuration is as follows:
Application is .NET Framework 3.5
Session State is handled by StateServer (running locally on web server)
StateServer service running on the web server is .NET Framework 4.0
There is only one web server, it is not a farm or garden situation
I have a page in the flow of control that sets a session variable to an instance of a custom user object (If I binary serialize the objects to the filesystem, their size can be between 6kb and 30kb, so not small, but not very large either). The application usually only has as many as 10 simultaneous users max. Subsequent pages in the flow of control, check that the session variable is not null. If the session variable is null, it is assumed that the session has timed out and the user is redirected to a "lost session" page. I have placed (for debugging purposes) another check on that same session object in the lost session page.
What I'm seeing in the logs is very strange -- users are being sent to the lost session page, but the object does indeed exist in the session! Is it possible that the session variable be null on PageTwo.aspx but not null on LostSession.aspx? Is it possible that PageTwo.aspx is run too soon -- meaning the object has not yet been fully "written" to the Session StateServer?
Any ideas on how I can debug this further?
Because the user object exists in LostSession it should also exist in PageTwo. Since you use redirect there should be no problems with data being accessed too soon.
You could try to set a checkpoint on in PageTwo on the line where the user object is being assigned and look into the session object manually. Comparing it with PageOne and LostSession might give you a clue what causes your issue.
It is possible that the key contains a typo and thus the user object is set to null, because the key referenced has no object in the session.
I had to update an old ASP+COM application for a customer when they went from Windows 2003 to 2008R2. The process, while not 100% painless, was sucessful but one problem remains: the application seems to randomly lose the session state or, at least, the session variable where I save the session's COM object.
Basically, the app works like this:
Login form page -> login page (object is created there and saved in Session("MyObject"), user credentials are checked -> First actual application page (Session("MyObject") is checked at the top of the code).
The Second redirect only happens if the credentials are correct but the object is always created.
However, users are reporting that they are frequently being redirected to the logon form page after entering their credentials.
After some investigation, it seems that the application properly goes through the login page, creates and instance of the COM object and redirect to the first application page. And there, the session variable is empty again and so the user is sent back to the login form.
What's more is that it is by far not systematic: the problem happens rather frequently but definitely not all the time. When it starts, users have to log on 2 or 3 times before they can get through. If the application is recycled, it usually solves the issue for some times although this isn't systematic and this isn't even always necessary.
Anyone has any idea what could be going on here ?
Edit: some extra info:
ASP session handling is active
In no part of the code are errors being silently suppressed. They will go to a log file if they happen somewhere the COM object can catch them or the user otherwise.
No error can be seen in the COM object log file, in the IIS log or in the server's event log.
Tracing the process activity with ProcMon didn't turn up anything special.
Looking at the COM object log file, I clearly see the COM object instance being created, the "LoginUser" method being called from the login page and returning successfully and then the first application page being called and the check for the existence of the object stored in the session failing.
There is a single web server, no server farm.
I did have an asp website that did exactly the same thing in the past. You need to check the log files and see if this application or website is running on it's own dedicated application pool and that the application pool is not being auto recycled due to bad code. If the session is being created then dropped, then pass the initital session value to another session - say Session("MyObject2") and check for that in the main page. If the users are still getting logged off then I am sure that the application pool is being recycled due to too many failures such as a redirect infinite loop or something else.
Edit: One more thing. I used to see such errors a lot when using ASP with MS Access and could never figure that out.
As a debugging exercise, I'd be tempted to log info from the ASP Session events including the session OnStart, OnEnd and abandon. Maybe try and get as much info from the request and then work out a given lifecycle/page flow for sessions and then determine if there is anything in common that occurs when the session is either ended or abandoned.
Also, while looking up the Session_OnEnd event, I came across an article that suggests it behaves weirdly in IIS 7.0 See http://blogs.iis.net/lprete/archive/2009/01/04/session-onend-classic-asp-and-iis-7-0.aspx just in case this might be of use.
Good luck.
I'm a little confused about the life cycle of the session in ASP.NET, here is my test case.
A user logs in, I save some info to a session variable (e.g. Session["bob"]="bob") then I do an "IIS reset". The user is still logged in, but the session data is null (e.g Session["bob"].ToString() throws a NullReferenceException.
I expected the session data to still be around. Is there something I can do, other than log out the user? I expected the session data to be around as long as the user is still logged in.
Any good links so I grok what's going on, as well as any help with the actual issue is greatly appreciated. I tried to Google this, but wasn't able to frame the question in a way to get what I wanted.
The behavior you are seeing - where the Session contents do not survive an IIS reset event - is due to where the Session values are stored. By default these values are stored within the memory of the ASP.NET "Worker Process", which is the program which runs your ASP.NET web site.
When you perform an "IIS reset" you shut down the entire IIS server, including the ASP.NET Worker Process. This means that the contents of the Session are removed from memory. Your user still appears to be logged in because that is controlled by the cookie stored in their browser. If the cookie is still valid, the login is.
If you wish your Session state to survive an IIS reset (or anything else which causes the ASP.NET worker process to restart) you'll need to store your Session objects in another place. This is fully supported by ASP.NET by using different Session storage "Modes". Read about those in the MSDN article "Session-State Modes".
For a general overview of the Session, check out the "ASP.NET Session State Overview" article on MSDN.
yah its right but some time its happen then session no remove properly at that time
you have to check session like
If Session("username") = nothing then
Response.redirect("~/default.aspx")
End if