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: "Mr. Arnold" MR. on 22 Jul 2010 20:27 "3P" <nospam(a)serwer.pl> wrote in message news:op.vf9ql2jpmsp0fz(a)mcs... >> 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. It was an async thread with no return. So the pages were not waiting for a return, which was using an async WCF Web service on the back-end, a Web service farm. There were no performance issues. The main point was to get the object back into session if it was lost -- no matter what caused the session to be lost with IIS resets being done 5 to 6 times throughout the day, which was used worldwide 24/7. It was a critical application within the enterprise level solution, but it was not a high usage application within the total enterprise solution.
From: "Mr. Arnold" MR. on 22 Jul 2010 20:52 "3P" <nospam(a)serwer.pl> wrote in message news:op.vf9rpk0umsp0fz(a)mcs... > > >> >> 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. I am confused here. Were you working on this application? I don't recall seeing you anywhere. You have no clue as to what you're talking about as to how the total enterpeise level application worked and the specifications that were given. This was not a situation where the user was sent to the login page or any other page. > > And what if someone gives someone else link with his GUID in it? Will that > other person > steal the object? It didn't happen. They didn't give out the URL for this closed to the public Internet solution. > Or will they concurently use same object? What when someone changes > the GUID in address by accident? If they were dumb enough change the GUID on the URL, then it was going to blow because, it couldn't find the session object based on the variable name having part of the guid as the name, and they were not dumb enough to change the other parms on the URL either. If this was a problem, then I wouldn't have gotten the specifications to do it what I did nor the approval. I don't recall you creating specifications nor did I see you in the development and testing phases either. Gee! You need to stick to what you know, and not projecting as to what you think should be happening. You were not there. I was there.
From: JK on 23 Jul 2010 04:51 Brian Cryer a �crit : > > 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. Right! I've found a hack in the code trying to set the timeout for this cookie. I've removed it and it seems better so far. I'm still testing. Many thanks for all Brian JM
From: 3P on 23 Jul 2010 08:45 Dnia 23-07-2010 o 02:52:09 Mr. Arnold <MR. <Arnold(a)arnold.com> napisa�(a): > > "3P" <nospam(a)serwer.pl> wrote in message news:op.vf9rpk0umsp0fz(a)mcs... >> >> >>> >>> 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. > > I am confused here. Were you working on this application? I don't recall > seeing you anywhere. You have no clue as to what you're talking about > as to how the total enterpeise level application worked and the > specifications that were given. This was not a situation where the user > was sent to the login page or any other page. > >> >> And what if someone gives someone else link with his GUID in it? Will >> that other person >> steal the object? > > It didn't happen. They didn't give out the URL for this closed to the > public Internet solution. > >> Or will they concurently use same object? What when someone changes >> the GUID in address by accident? > > If they were dumb enough change the GUID on the URL, then it was going > to blow because, it couldn't find the session object based on the > variable name having part of the guid as the name, and they were not > dumb enough to change the other parms on the URL either. If this was a > problem, then I wouldn't have gotten the specifications to do it what I > did nor the approval. > > I don't recall you creating specifications nor did I see you in the > development and testing phases either. > > Gee! You need to stick to what you know, and not projecting as to what > you think should be happening. You were not there. I was there. > > Now I know for sure. You are plain dumb. I kindly asked and You are attacking me. And BTW this is very ugly solution. You don't know a lot about ASP.NET as You shown in this thread.
From: 3P on 23 Jul 2010 09:56
> It was an async thread with no return. So the pages were not waiting > for a return, which was using an async WCF Web service on the back-end, > a Web service farm. There were no performance issues. The main point was > to get the object back into session if it was lost -- no matter what > caused the session to be lost with IIS resets being done 5 to 6 times > throughout the day, which was used worldwide 24/7. It was a critical > application within the enterprise level solution, but it was not a high > usage application within the total enterprise solution. Well every thread is async. I know page wasn't waiting for thread to finish, but still two worker threads were used for every page load/unload. But You said it wasn't high usage app. That's probably why You didn't see performance penalty. |