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: JK on 21 Jul 2010 07:36 Brian Cryer a �crit : > > 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. > Brian, I think you were right. It seems that my session ID has changed. Here my log where I print sessions: 21/07/2010 12:36 : -- SESSION ID is:hghggu45kp3zfg55kiovs0ae timeout:60 21/07/2010 12:36 : -- USER ID is: 1 21/07/2010 12:36 : -- USER IS admin 21/07/2010 13:29 : -- SESSION ID is:yplwhojtqpox5uizuri4m434 timeout:60 21/07/2010 13:29 : -- USER IS NOTHING!! I just go to lunch (so there were no activity on both client and server) and then, the session ID has changed. How can this be possible ? JM
From: Brian Cryer on 21 Jul 2010 09:16 "JK" <JK(a)invalid.com> wrote in message news:4c46dbc1$0$2983$ba4acef3(a)reader.news.orange.fr... > Brian Cryer a �crit : > >> >> 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. >> > > Brian, > > I think you were right. It seems that my session ID has changed. > Here my log where I print sessions: > 21/07/2010 12:36 : -- SESSION ID is:hghggu45kp3zfg55kiovs0ae timeout:60 > 21/07/2010 12:36 : -- USER ID is: 1 > 21/07/2010 12:36 : -- USER IS admin > 21/07/2010 13:29 : -- SESSION ID is:yplwhojtqpox5uizuri4m434 timeout:60 > 21/07/2010 13:29 : -- USER IS NOTHING!! > > I just go to lunch (so there were no activity on both client and server) > and then, the session ID has changed. > > How can this be possible ? Interesting. Sadly no idea. As far as I'm aware the session id should NEVER change - the reason is simply because its tied to the browser (via a cookie). The exception being after a call to session.abandon. Did you have another browser window open on the same site? I think the cookie is tied to the domain, so if you had two applications in different folders on the same site/domain then presumably (I'm guessing here) they could interfere with each other. (I know you said you went to lunch so no activity, but just double checking.) My feeling is that either: 1. Its an application issue - something is explictly changing the session ID or the cookie ("ASP.NET_SessionId" I think) that .NET uses to keep track of the session ID. 2. Its a browser issue - the browser is loosing the cookie. On that vain, some anti-spyware applications treat cookies as a form of spyware (I think this is just so they can report something), so that might give another avenue to investigate. Only guesses I'm sorry to say. When you do find the cause (I'm sure you will find it eventually), I'd love to know what it was. -- Brian Cryer http://www.cryer.co.uk/brian
From: "Mr. Arnold" MR. on 21 Jul 2010 19:20 "Brian Cryer" <not.here(a)localhost> wrote in message news:%23M9p2bNKLHA.6100(a)TK2MSFTNGP05.phx.gbl... <snipped> After watching this whole abomination with an ASP.NET State service and a custom object, I now know to avoid it at all cost, and do it myself. That also includes not doing it with a SQL Server State server too.
From: Brian Cryer on 22 Jul 2010 04:55 "Mr. Arnold" <MR. Arnold(a)Arnold.com> wrote in message news:e0uZwtSKLHA.4312(a)TK2MSFTNGP02.phx.gbl... > > "Brian Cryer" <not.here(a)localhost> wrote in message > news:%23M9p2bNKLHA.6100(a)TK2MSFTNGP05.phx.gbl... > > <snipped> > > After watching this whole abomination with an ASP.NET State service and a > custom object, I now know to avoid it at all cost, and do it myself. That > also includes not doing it with a SQL Server State server too. SQL Server state is a whole lot slower. Never used it myself. If you had been following the thread closely you will have seen that the problem turns out to be that the session-id is being lost. (Session-id is not itself stored in the session.) If the session-id is being lost then this will affect any session regardless of the mechanism used to main it (in-proc, state or sql server). If you can suggest how the OP might investigate the cause of this then that would be helpful. Given that the problem turns out to have nothing to do with using state service, to referring to it as an "abomination" is just daft. -- Brian Cryer http://www.cryer.co.uk/brian
From: "Mr. Arnold" MR. on 22 Jul 2010 09:11
"Brian Cryer" <not.here(a)localhost> wrote in message news:ear8kuXKLHA.1868(a)TK2MSFTNGP05.phx.gbl... > "Mr. Arnold" <MR. Arnold(a)Arnold.com> wrote in message > news:e0uZwtSKLHA.4312(a)TK2MSFTNGP02.phx.gbl... >> >> "Brian Cryer" <not.here(a)localhost> wrote in message >> news:%23M9p2bNKLHA.6100(a)TK2MSFTNGP05.phx.gbl... >> >> <snipped> >> >> After watching this whole abomination with an ASP.NET State service and a >> custom object, I now know to avoid it at all cost, and do it myself. That >> also includes not doing it with a SQL Server State server too. > > SQL Server state is a whole lot slower. Never used it myself. I have used it in a couple of shops. It was OK, and I didn't really see any performance issues using a SQL State server. > > If you had been following the thread closely you will have seen that the > problem turns out to be that the session-id is being lost. (Session-id is > not itself stored in the session.) If the session-id is being lost then > this will affect any session regardless of the mechanism used to main it > (in-proc, state or sql server). If you can suggest how the OP might > investigate the cause of this then that would be helpful. The easiest thing to do would be to have a base page that all other pages are derived from, and the base page would have a hidden field that would hold the Session-ID that was saved on initial access of the application, and other pages can access the basepage.SessionID. > > Given that the problem turns out to have nothing to do with using state > service, to referring to it as an "abomination" is just daft. No, it's about the manner in which State Service is being used in this situation that I find questionable. There are other ways to keep a custom object in state without depending upon State Service. |