When I store a value in a session and some exception occurs afterwards, the session state might not be persisted.
Session["MyKey"] = value;
throw new Exception("Test exception");
I found out that if I'm using InProc mode, the value gets persisted immediately, so if an exception occurs, it's stored anyway.
But if I switch to StateServer mode, the value will not get persisted if an exception occurs. I can write to the session, read it again from the session, but after an exception occurs, it's like all the changes I made to the session state in that request will be discarded (i.e. not persisted). And any future request will read the "old" state of the session.
At first I was thinking that it's related to the session cookie not being sent in response in case of the exception, but this behavior occurs for sessions that already exist and users already hold their identifiers. It also clearly differs from InProc to StateServer, while both of these approaches handle cookies the same way, it's just the persistance layer that is different.
How does the session state persistance work? At which point in the request lifecycle are the changes actually persisted to StateServer? Is it possible to force persisting of the session state, so it would be persisted even after an exception occurs?
The docs says
https://msdn.microsoft.com/en-us/library/system.web.httpapplication.releaserequeststate.aspx
HttpApplication.ReleaseRequestState Event. Occurs after ASP.NET finishes executing all request event handlers. This event causes state modules to save the current state data.
Related
In out project we need to execute a few AJAX calls in a row asynchronously, so the next call doesn't have to wait for previous to return. And even though client issues calls asynchronously, server processes them sequentially due to Session lock.
Since we don't need to modify Session in these calls, we marked page that AJAX calls with EnableSessionState="ReadOnly"via #Page directive. And it worked, calls became truly async and no longer depend on each other timing. But what we found out - in that backend code Session is writable despite being marked as ReadOnly. We can assign values to Session and the values persist. Is this a bug or behavior by design?
I'd say this behavior is a "by design" gotcha of in-process session state (which, unfortunately, doesn't seem to be well documented).
Out-of-Process Session State (State Server or SQL Server)
At the beginning of every request, ASP.NET loads and deserializes session data from external storage into memory. Each request gets its own copy of the data, so changes to the data won't affect other concurrent requests in the same session.
if EnableSessionState is set to ReadOnly, then at the end of the request, the data are simply discarded rather than serialized back to external storage.
In-Process Session State
No serialization or deserialization occurs. Instead, there's a single set of session data in memory which lives for the duration of the session. Each request in the same session shares that set of data, and changes to the data are immediately visible to other concurrent requests.
I suppose the ASP.NET team could have made Session read only when EnableSessionState is set to ReadOnly:
this.Session["Customer"] = customer; // Why not throw InvalidOperationException?
But ASP.NET would still have no way of detecting changes to the objects themselves:
Customer customer = (Customer)this.Session["Customer"];
customer.Address = address; // ASP.NET can't detect this.
Therefore, it's your responsibility as a developer to avoid changing session data if you set EnableSessionState to ReadOnly. Otherwise, you may introduce multithreading bugs.
I expect that if controller has attribute SessionStateBehavior.ReadOnly then I can't change session variables inside this controller
but I can change values.
I try this code
[SessionState(System.Web.SessionState.SessionStateBehavior.ReadOnly)]
public class GLobalController : Controller
{
public ActionResult Index()
{
Session["xxx"] = DateTime.Now.ToString();
return View();
}
see Writing to a read only session in MVC 3+
That post claims the behavior is inconsistent.
I am definitely able to write to Session in Controllers using ReadOnly.
I Would treat it like this:
Required means you are requesting a exclusive lock on Session (i.e. no parallel processing of requests for the same sessionID)
ReadOnly means you are requesting a non-exclusive lock on Session (i.e. your request still has to wait for requests with an exclusive lock to finish, but you can process requests with non-exclusive locks in parallel. However it is up to you to ensure that your code doesn't write to Session. It's not necessarily enforced by the framework)
I realize this is counter to http://msdn.microsoft.com/en-us/library/system.web.sessionstate.sessionstatebehavior.aspx
Read-only session state is enabled for the request. This means that session state cannot be updated.
but it seems you in fact can update session state under some scenarios.
According to Patrick Y. Ng (Software Engineer at Microsoft) who designed and developed the Session State engine of ASP.NET:
Even though EnableSessionState is marked as ReadOnly, in InProc state the user can still modify the session. The only difference is that the session will not be locked during the request. This limitation is by-design. And I'm sorry that it’s not documented in MSDN.
There is much more useful information about session state in this post. It is really worth reading.
This is just my interpretation:
I see that you can add to Session during the action method - after all Session is just a dictionary really. However the session is not saved at the end.
It does seem like it ought to throw an exception, but perhaps since this feature came later to the framework they decided against checking every time.
Results may vary also depending upon what session state storage you are using (inproc / sql server).
Session invalidation means session destroying.So if session is destroyed,it indicates that server cant identify the client which has visited in previous.So now it creates a new session id for that client.
Is this right?If wrong tell me the correct procedure.
Calling HttpSession.invalidate() simply clears any object that is bound to it and marks it as invalid, so if you try to modify it afterward it will throw exceptions.
Once a session has been invalidated, the SessionID placed in a cookie on the client will be invalid too, and a new one will have to be created when a new session object is created. So the new Session will have a new ID.
This is usefull to handle for example login/logout. Sessions should always be invalidated at login to help prevent Session fixation attacks
Yes, absolutely right. Invalidating a session will mark the session as invalid and will be destroyed. If the client comes with the session id which has been invalidated a new session will be created.
session.inValidate():
If we are logging into gmail then at server side server will create session object
If we are calling session.inValidate() method means we are logged out since session object is destroyed by the server.
During Session Start, one has access to the Request object. How about Session End, does it still have access to the Request object ? For example I want to count how many browsers are currently connected to my application.
Edit 1 : If Session End doesn't have access to Request Object, what info does it have access to ? Session ID, etc ?
Edit 2 : If Session End cannot be used to track disconnections, how does one track disconnections in ASP.Net ?
Thanks
No, the Request object is not available in Session End.
Note too that Session End only fires when you call Session.Abandon() from code, not when a Session expires due to natural timeout or what-have-you. Consequently, it is not a reliable method to use for tracking disconnections.
Session_End will be fired if one is using InProc.
Session_End will be fired
1) after n minutes of inactivity (n = timeout value), or
2) if someone calls Session.Abandon()
Session_End doesn't get fired if one closes the browser.
Session_End requires session state to be set.
If one needs the original Request.Browser data, one should save it in Session State.
During Session_End, it has access to the Session State.
from the documentation
The Session_OnEnd event occurs when a
session is abandoned or times out. Of
the Server built-in objects, only the
Application Object, Server Object, and
Session Object objects are available.
Remarks
You cannot call the Server.MapPath
method in the Session_OnEnd script. By
default, Session_OnEnd runs as the
Anonymous User, as defined for the
application. In the event that there
isn't an Anonymous user, or the Logon
for the Anonymous user fails, the
OnEnd function will not be called, and
an event will be logged.
Recently, while working on some code for an ASP.NET project at work. We needed a tracking util to take basic metrics on user activity (page hit count etc) we would track them in Session, then save the data to DB via Session_End in Global.asax.
I began hacking away, the initial code worked fine, updating the DB on each page load. I wanted to remove this DB hit on each request though and just rely on Session_End to store all the data.
All of the tracking code is encapsulated in the Tracker class, including properties that essentially wrap the Session variables.
The problem is that when I executed Tracker.Log() in the Session_End method, the HttpContext.Current.Session in the Tracker code was failing with a NullReferenceException. Now, this makes sense since HttpContext always relates to the current request, and of course in Session_End, there is no request.
I know that Global.asax has a Session property which returns a HttpSessionState that actually seems to work fine (I ended up injecting it in to the tracker)..
But I am curious, how the hell can I get the same reference to the HttpSessionState object used by Global.asax from outside of Global.asax?
Thanks in advance guys, I appreciate the input. :)
To answer the original question better:
Background
Every single page request spins up a new Session object and then inflates it from your session store. To do this, it uses the cookie provided by the client or a special path construct (for cookieless sessions). With this session identifier, it consults the session store and deserializes (this is why all providers but InProc need to be Serializable) the new session object.
In the case of the InProc provider, merely hands you the reference it stored in the HttpCache keyed by the session identifier. This is why the InProc provider drops session state when the AppDomain is recycled (and also why multiple web servers cannot share InProc session state.
This newly created and inflated object is stuck in the Context.Items collection so that it's available for the duration of the request.
Any changes you make to the Session object are then persisted at the end of the request to the session store by serializing (or the case of InProc, the HttpCache entry is updated).
Since Session_End fires without a current request in-fly, the Session object is spun up ex-nilo, with no information available. If using InProc session state, the expiration of the HttpCache triggers a callback event into your Session_End event, so the session entry is available, but is still a copy of what was last stored in the HttpContext.Cache. This value is stored against the HttpApplication.Session property by an internal method (called ProcessSpecialRequest) where it is then available. Under all other cases, it internally comes from the HttpContext.Current.Session value.
Your answer
Since the Session_End always fires against a null Context, you should ALWAYS use this.Session in that event and pass the HttpSessionState object down to your tracing code. In all other contexts, it's perfectly fine to fetch from HttpContext.Current.Session and then pass into the tracing code. Do NOT, however, let the tracing code reach up for the session context.
My answer
Don't use Session_End unless you know that the session store you are using supports Session_End, which it does if it returns true from SetItemExpireCallback. The only in-the-box store which does is the InProcSessionState store. It is possible to write a session store that does but the question of who will process the Session_End is kind of ambiguous if there are multiple servers.
Global.asax implements HttpApplication - which is what you are talking to when you call this from within it.
The MSDN documentation for HttpApplication has details on how you can get hold of it in an HttpHandler for example, and then get access to the various properties on it.
HOWEVER
Your application can create multiple instances of HttpApplication to handle parallel requests, and these instances can be re-used, so just picking it up somehow isn't going to guarentee that you have the right one.
I too would also add a note of caution - if your application crashes, there's no guarentee that session_end is going to be called, and you'll have lost all the data across all sessions, clearly not a good thing.
I agree that logging on every page is probably not a great idea, but perhaps a halfway house with some asynchronous logging happening - you fire details off to a logging class, that every now and then logs the details you are after - still not 100% solid if the app crashes, but you're less likely to lose everything.
I think you already answered your own question: usually the Session property in Global.asax and HttpContext.Current.Session are the same (if there is a current request). But in the case of a session timeout, there is no active request and therefore you can't use HttpContext.Current.
If you want to access the session from the method called by Session_End, then pass it as a parameter. Create an overloaded version the Log() method, which takes a HttpSessionState as a parameter, then call Tracker.Log(this.Session) from the Session_End event handler.
BTW: you are aware that you can not rely on the session end event in any case? It will only work as long as you have the session state in-process. When using SQL server or StateServer to mange the session state, the session end event will not fire.
The Session_End event is raised only when the sessionstate mode is set to InProc in the Web.config file. If session mode is set to StateServer or SQLServer, the event is not raised.
use Session["SessionItemKey"] to get the session value.
Okay, I am in the same problem to track the session activity. Instead of using session_end event, I have implemented the IDisposable interface and destructor to my sessiontracker class. I have modified the Dispose() method to save the session activity to DB. I invoked the method obj.Dispose() when a user clicks the logout button. If user closed the browser by mistake, then GC will call the destructor while cleaning the objects (not immediately but for sure it will call this method after sometime). The destructor method internally execute the same Dispose() method to save the session activities into DB.
-Shan
Session is available in your Global.asax file, during the Session_Start event. Maybe wait until this point to do stuff?
Remember that Session_End runs when the session times out without activity. The browser doesn't originate that event (because it's inactive), so the only time you actually will get the event is when using the InProc provider. In EVERY OTHER provider, this event will never fire.
Moral? Don't use Session_End.