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 22 Jul 2010 10:14 "Mr. Arnold" <MR. Arnold(a)Arnold.com> wrote in message news:Oi%23T69ZKLHA.5464(a)TK2MSFTNGP02.phx.gbl... > > "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. Good to know. TA. >> 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. But this is just re-implementing what the framework is supposed to be doing for us anyway. That said, it might be the basis for quite a good work around - hope the OP is still paying attention! >> 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. Okay, I see where you are coming from. Fair enough. -- Brian Cryer http://www.cryer.co.uk/brian
From: Mr. Arnold on 22 Jul 2010 11:21 On 7/22/2010 10:14 AM, Brian Cryer wrote: > "Mr. Arnold" <MR. Arnold(a)Arnold.com> wrote in message > news:Oi%23T69ZKLHA.5464(a)TK2MSFTNGP02.phx.gbl... >> >> "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. > > Good to know. TA. > >>> 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. > > But this is just re-implementing what the framework is supposed to be > doing for us anyway. > That said, it might be the basis for quite a good work around - hope the > OP is still paying attention! > >>> 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. > > Okay, I see where you are coming from. Fair enough. I had a situation where I couldn't use the session-id, which would have been concatenated at the end of a session custom object name that needed to be passed around from page to page. The reason I couldn't use the session-id is another story, and I don't want to get into it. And my solution was to ToString() a Guid and concatenated the GUID to session custom object name. So the application started up on a certain page when doing a creation of user information, and it started-up on certain page when maintenance was being done to the existing user information. The original GUID assigned had to be passed from page to page to construct the session object name for the custom object to set/get session object. How I did it was the two pages that were used for create/maint would initially get a new GUID at page-load !postback. It would save the string Guid to a hidden field, which was on all the pages for this application. As each page did a redirect to another page, the GUID was taken from the hidden field and passed on the URL. The pages would determine at their page-load if it was a postback or not. It was not a postback (redirect from another page), the page would querystring for the GUID on the URL and save it to its hidden field for the GUID. If it was a postback then, the page would go to the hidden field to get the GUID, because the URL no-longer had the GUID on the URL on postback. In either case, I always had the initial GUID that was trapped on my two start pages to be passed around to the other pages to construct the session variable name to get/set. Even if the page timed-out, the GUID was not lost as the page kept GUID using a hidden field state. If one is not inclined to use a base page to hold Session-ID, one could use what I have talked about to trap the Session-ID and pass it around and not loose it.
From: 3P on 22 Jul 2010 19:38 > 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. :) Because this is custom logic. Not typical session usage. Can I ask if You did some performance measuring? What I find weird is spawning another thread in PageUnload. Thus You use two worker threads for each client and that will decrease performance of application.
From: 3P on 22 Jul 2010 19:39 Dnia 20-07-2010 o 11:03:04 Brian Cryer <not.here(a)localhost> napisa�(a): > "3P" <nospam(a)serwer.pl> wrote in message news:op.vf4vjhi3msp0fz(a)mcs... >> Are You saving/deleting any files under Your website's folder structure. >> >> Add logging application restarts to global.asax. > > One of the advantages in using the stateserver for state is that it > doesn't matter if the application gets recycled. Recycling is only an > issue with state if you use in-proc. I didn't pay enough attention to OP. I didn't notice it was state-server.
From: 3P on 22 Jul 2010 20:01
> > I had a situation where I couldn't use the session-id, which would have > been concatenated at the end of a session custom object name that needed > to be passed around from page to page. The reason I couldn't use the > session-id is another story, and I don't want to get into it. > > And my solution was to ToString() a Guid and concatenated the GUID to > session custom object name. So the application started up on a certain > page when doing a creation of user information, and it started-up on > certain page when maintenance was being done to the existing user > information. > > The original GUID assigned had to be passed from page to page to > construct the session object name for the custom object to set/get > session object. > > How I did it was the two pages that were used for create/maint would > initially get a new GUID at page-load !postback. It would save the > string Guid to a hidden field, which was on all the pages for this > application. As each page did a redirect to another page, the GUID was > taken from the hidden field and passed on the URL. > > The pages would determine at their page-load if it was a postback or > not. It was not a postback (redirect from another page), the page would > querystring for the GUID on the URL and save it to its hidden field for > the GUID. If it was a postback then, the page would go to the hidden > field to get the GUID, because the URL no-longer had the GUID on the URL > on postback. In either case, I always had the initial GUID that was > trapped on my two start pages to be passed around to the other pages to > construct the session variable name to get/set. > > Even if the page timed-out, the GUID was not lost as the page kept GUID > using a hidden field state. > > If one is not inclined to use a base page to hold Session-ID, one could > use what I have talked about to trap the Session-ID and pass it around > and not loose it. > I'm not sure how is that different than storing that GUID in session. If session times out You will still loose that hidden field GUID because You will be redirected to login page. And what if someone gives someone else link with his GUID in it? Will that other person steal the object? Or will they concurently use same object? What when someone changes the GUID in address by accident? |