Response.Redirect or End
We have a new issue as a result of moving the NHiberSession to HttpSessionState.
In short, whenever a Response.Redirect or a Response.End is called, the Global_ReleaseRequestState is bypassed. Instead, a ThreadAbortException is raised (as you may know) and then Application_EndRequest is raised directly.
This is normal.
In our case though, before Application_EndRequest, a SerializationException exception is raised because our NHiberSession is still connected. NHiberSession cannot be serialized when connected and it can only be disconnected in Global_ReleaseRequestState since we need the session for it.
I tried to store the NHiberSession (a similar sample object) in System.Web.HttpRuntime.Cache and disconnect it in Application_EndRequest but as you can infer from the above, the Session has already been unsuccessfully serialized by then and this has no effect.
Yes, specifying the second parameter as false solves the Response.Redirect problem.
In fact, this is supposed to be the correct way of using Response.Redirect. The single parameter version supposedly is just a VB-legacy carry-over.
But that again means
1. Ensuring that the second parameter is false in all places and that continuing execution won’t cause any problems
2. The Response.End problem still remains (This problem is far lesser in number though)
Yes, this is a good alternative - second parameter false for Response.Redirect and Disconnect/DestroyNHiberSession for Response.End
What I was trying was for a global solution that wouldn’t depend on or restrict the implementation of Response.Redirect or End
That looks difficult at this point.
--
It’s working now.
What I’ve done now is made a new EventHandler called Global_EndRequest, just like Global_ReleaseRequestState.
Both Global_ReleaseRequestState and Global_EndRequest have the Session object available when they called as opposed to their normal counterparts - Application_ReleaseRequestState and Application_EndRequest
(Global_EndRequest will have the Session only after ThreadAbortException and not in the normal flow when it is called AFTER Global_ReleaseRequestState - The comments provided in the code should be more informative)
That should take care of both the ThreadAbortException causing Response.Redirect or End calls.
But we should be using the second parameter as false for Response.Redirect everywhere [anyway].
--
Incidentally, this setup works fine even for an Application_Error, in a way similar to Response.Redirect or End calls.
In short, whenever a Response.Redirect or a Response.End is called, the Global_ReleaseRequestState is bypassed. Instead, a ThreadAbortException is raised (as you may know) and then Application_EndRequest is raised directly.
This is normal.
In our case though, before Application_EndRequest, a SerializationException exception is raised because our NHiberSession is still connected. NHiberSession cannot be serialized when connected and it can only be disconnected in Global_ReleaseRequestState since we need the session for it.
I tried to store the NHiberSession (a similar sample object) in System.Web.HttpRuntime.Cache and disconnect it in Application_EndRequest but as you can infer from the above, the Session has already been unsuccessfully serialized by then and this has no effect.
Yes, specifying the second parameter as false solves the Response.Redirect problem.
In fact, this is supposed to be the correct way of using Response.Redirect. The single parameter version supposedly is just a VB-legacy carry-over.
But that again means
1. Ensuring that the second parameter is false in all places and that continuing execution won’t cause any problems
2. The Response.End problem still remains (This problem is far lesser in number though)
Yes, this is a good alternative - second parameter false for Response.Redirect and Disconnect/DestroyNHiberSession for Response.End
What I was trying was for a global solution that wouldn’t depend on or restrict the implementation of Response.Redirect or End
That looks difficult at this point.
--
It’s working now.
What I’ve done now is made a new EventHandler called Global_EndRequest, just like Global_ReleaseRequestState.
Both Global_ReleaseRequestState and Global_EndRequest have the Session object available when they called as opposed to their normal counterparts - Application_ReleaseRequestState and Application_EndRequest
(Global_EndRequest will have the Session only after ThreadAbortException and not in the normal flow when it is called AFTER Global_ReleaseRequestState - The comments provided in the code should be more informative)
That should take care of both the ThreadAbortException causing Response.Redirect or End calls.
But we should be using the second parameter as false for Response.Redirect everywhere [anyway].
--
Incidentally, this setup works fine even for an Application_Error, in a way similar to Response.Redirect or End calls.
Comments
Post a Comment