losing sessions when running in StateServer mode
in [ASP .NET]
|
Prev: System.Web.IHttpHandler, System.Web.SessionState.IRequiresSess
Next: Looking for a NNTP server that discuss csharp/.net
From: Brian Cryer on 20 Jul 2010 05:59 "Mr. Arnold" <Arnold(a)Arnold.com> wrote in message news:upnWo3%23JLHA.2276(a)TK2MSFTNGP06.phx.gbl... > On 7/20/2010 5:11 AM, JK wrote: >> Mr. Arnold a �crit : >> >>> >>> But how would an application know about the session variables it had >>> when W3WP.exe was recycled?. Everything is lost I would think. And >>> that must be the case, because you're talking about even with a >>> session start server in the infrastructure. >>> >> >> Because the sessions variables are held by the state server! >> It seems it is designed for this. >> >> JM > > No, I don't think so, and I think you have a miss understanding as to > what is really happening when session is lost and you recycled WPW3.exe. YES. The state server is designed for this. I suggest you read up on the state server as your answers are implying a knowledge of "in-proc" and not "state-server". On any one of the servers I look after I can recycle the worker process knowing that the session is preserved. This also means I can update any one of my live sites without any disruption to the users (other than perhaps a performance blip.) > Why would you be talking about this, if things are working the way you > think it is and session information is somehow to comeback as is when > things have been disrupted for an application. Because its not behaving for the OP how it should, hence the question. With session state you should only loose the session information if you explicitly abandon the session, restart the state server or the session timeout is reached. -- Brian Cryer http://www.cryer.co.uk/brian
From: Brian Cryer on 20 Jul 2010 06:05 "JK" <JK(a)invalid.com> wrote in message news:4c45707c$0$2994$ba4acef3(a)reader.news.orange.fr... > Brian Cryer a �crit : >> "Brian Cryer" <not.here(a)localhost> wrote in message >> news:OsBP$0%23JLHA.6100(a)TK2MSFTNGP05.phx.gbl... >> >> Two suggestions: >> >> 1. Are you calling session.abandon anywhere? >> >> 2. Are you resetting the session timeout anywhere? (Not sure if this >> works with state-server anyway, but worth asking the question.) >> >> 3. Are you running in a web-garden or web-farm environment? A web-garden >> is multiple cpus [not cores], but I don't think a web-garden will cause >> problems. A web-farm is where you have multiple servers, in this case you >> there is a little bit of extra config to ensure that they each use the >> same state and don't have the information pertitioned on the >> state-service on a per-machine basis - see >> http://support.microsoft.com/default.aspx?scid=kb;en-us;325056 for >> details. > > > Hi Brian, > > Answer is No for 3 questions. > > I just had an idea and I'm doing some testing to validate. > > My session variable is a Custom Object we created. > If, for any reason, the application is being recompiled, maybe the object > stored in state server will be lost. No but yes (possibly)!!! When an object is stored in the session it is serialized and the serialized version stored in the state-server. Part of that serialization process is to store the (for want of a better word) "version" of the object. This seems to be made up of the name of the dll that visual studio creates at compile time plus some other bits. When you recompile the name of that dll will change which means you might not be able to deserialize your object. If this is the case then other session variables would be maintained, just your object lost. I can't say catagorically that that's the problem, but I have stored serialized objects in a database and then encountered deserialisation issues after a recompile (which is why I don't do that any more), so it probably also applies to state. This of course assumes a recompile. If you are not recompiling then it shouldn't matter nor should a recycle of the worker process make any difference. > I'm tyring to see whether simple variables (e.g Integers) are also lost. Do look to see whether the sessionID is being preserved. -- Brian Cryer http://www.cryer.co.uk/brian
From: JK on 20 Jul 2010 06:16 Brian Cryer a �crit : > a recompile (which is why I don't do that any more), so it probably also > applies to state. This of course assumes a recompile. If you are not > recompiling then it shouldn't matter nor should a recycle of the worker > process make any difference. > I'm not recompiling but sometimes it is done automatically when files are changed. Note that the object stored in the session has not been changed for ages. > > Do look to see whether the sessionID is being preserved. I can check the cookie on the client. Is there something to check on the server ? Thanks, JM
From: Mr. Arnold on 20 Jul 2010 06:28 On 7/20/2010 5:53 AM, Brian Cryer wrote: > "Mr. Arnold" <Arnold(a)Arnold.com> wrote in message > news:eHHfz$%23JLHA.1016(a)TK2MSFTNGP06.phx.gbl... >> On 7/20/2010 5:32 AM, Brian Cryer wrote: >>> >>> "Mr. Arnold" <Arnold(a)Arnold.com> wrote in message >>> news:%23DOd7z%23JLHA.3732(a)TK2MSFTNGP02.phx.gbl... >>>> On 7/20/2010 5:10 AM, Brian Cryer wrote: >>>>> "Mr. Arnold" <Arnold(a)Arnold.com> wrote in message >>>>> news:u7$DQp%23JLHA.1868(a)TK2MSFTNGP05.phx.gbl... >>>>>> On 7/20/2010 4:54 AM, JK wrote: >>>>>>> 3P a �crit : >>>>>>>> Are You saving/deleting any files under Your website's folder >>>>>>>> structure. >>>>>>>> >>>>>>>> Add logging application restarts to global.asax. >>>>>>> >>>>>>> I have no global.asax. >>>>>>> However, when running state server, is that important ? >>>>>>> I've read somewhere that unless you restart state server, you never >>>>>>> lose >>>>>>> sessions variables. >>>>>>> >>>>>> >>>>>> But how would an application know about the session variables it had >>>>>> when W3WP.exe was recycled?. Everything is lost I would think. And >>>>>> that must be the case, because you're talking about even with a >>>>>> session start server in the infrastructure. >>>>> >>>>> All variables are lost yes, but not session unless you are using >>>>> in-proc. With state-server the session information is serialized and >>>>> stored in a separate asp.net state server process. The session ID is >>>>> stored in a cookie (I think), so is available to the server on each >>>>> post-back or page-refresh, and it uses this to retrieve session >>>>> information from the asp.net state server process. So session >>>>> information is preserved across a recycle (which can be very useful >>>>> when >>>>> debugging as you can compile and then continue without having to >>>>> re-login). >>>> >>>> But if the session is lost by the application how is IIS going to know >>>> what session information belonged to what application? I don't think >>>> IIS is doing application tracking too with a state server. Now maybe, >>>> the programmer can take over and program for it in the application and >>>> go after the state information and restore it. >>>> >>>> But without doing that, I don't see how it's going to get session back >>>> for the application without some type of intervention initiated by the >>>> application itself. >>> >>> Sorry I thought I explained that. The session-id is sent to the browser, >>> normally in a cookie. It is then posted back to the server on every >>> post-back or page-refresh. So the server (by which I mean the asp.net >>> framework running on the server, not IIS which couldn't care less) >>> always has the session-id. So the session-id is always available. The >>> session-id is then used when the asp.net state service is contacted to >>> retrieve the session information. >>> >>> That is how session information is preserved across a recycle. >> >>> >>> Now, if you use in-proc then the session information would be stored in >>> the worker process so if the worker process were recycled then the >>> session information would be lost. The OP is using state-server so the >>> session information is stored externally to the worker process and thus >>> is preserved across a recycle. >>> >>> Does that help clarify things? >> >> But what you're talking about is based on using a cookie. What if the >> application is not using cookies then what? > > Don't know. It could store it as a separate variable in the HTML much > like viewstate or even in the viewstate, but I'm speculating because I > don't know what asp.net does. This isn't something I've looked at. > > If something (like not using cookies) interferes with the session-id so > its lost then yes that could account for what the OP is seeing - which > is why I've posted suggesting he look at whether the session-id is > preserved when the session is lost. You know, I had a situation where I had a custom object in session with many object graphs in it that was being passed around from page to page, and the pages populated the object and object graphs in the custom object. All this was in-proc, and if session timed-out, IIS reset, the user got up and walked way for days and came back to the machine with the browser still opened on one of these pages, the application had to get the custom object back and put it back into session as if nothing had happened. On every page-unload, I would spawn a thread, serialized the object and sent it to my custom SQL server state table for this particular application. All I had to do was to detect that the custom object was null in memory, and I went back to my state table and get the last known object back, deserialized it and put the object back into session. The objects were not saved to my state table based on a session-id and there was other information I could use like user-id and a couple of other ID(s) in the session being used by the user that made things unique for my state records. If things are that critical and you have to get the object back based on a last version that was successfully saved, I don't think I would be depending upon a session state service of SQL State server to do it. That's how I look at it. :)
From: Brian Cryer on 20 Jul 2010 06:31
"JK" <JK(a)invalid.com> wrote in message news:4c457766$0$27601$ba4acef3(a)reader.news.orange.fr... > Brian Cryer a �crit : > >> a recompile (which is why I don't do that any more), so it probably also >> applies to state. This of course assumes a recompile. If you are not >> recompiling then it shouldn't matter nor should a recycle of the worker >> process make any difference. >> > > I'm not recompiling but sometimes it is done automatically when files are > changed. Note that the object stored in the session has not been changed > for ages. I don't think that matters. Its only when recompiling in visual-studio that the names of the generated dll files change. >> >> Do look to see whether the sessionID is being preserved. > > I can check the cookie on the client. Is there something to check on the > server ? Simply display the value of Session.SessionID (or HttpContext.Current.Session.SessionID). Nothing more complex than that. For a given browser session as far as I'm aware this should never change - even across a session timeout. If it does change then that would account for the loss of session information, so the next task would be to identify why its changed. > Thanks, > JM -- Brian Cryer http://www.cryer.co.uk/brian |