0

I have a .NET Framework 4.7.2 web app running on IIS 10.0, and several users are reporting being kicked out of their sessions at about the same time every day. The users are still logged in when this happens, but they are sent to where they have to enter information specific to their current session.

I have the sessionState timeout set to 525600 (max value) in web.config, so I don't believe that's the issue.

Any ideas what may be causing this?

jbrown7061
  • 103
  • 1
  • 4
  • 1
    any app code error, or re-start can blow out the session(). Just setup sql server based session - it is seamless to existing code, and since I done that, then session() values are now bullet proof. – Albert D. Kallal Aug 06 '21 at 19:51
  • If I use SQL for session variables, how can I clear those out when a user closes their browser tab where they were using the app? That's the main reason I haven't done it that way. – jbrown7061 Aug 06 '21 at 19:54
  • I suggest you adopt use of ViewState. Session() is global to one user, and the fact that you lingering session() values should not matter while the application runs, or that the user exits, and comes back later - your designs should still work. In fact I adopted a code standard in which session() is ONLY used to pass vars (and even class objects) to the target page. But on page load, (postback = false), I transfer that/those values to View state. I do this, since if you are to buy a house, and two pages open, I can't use PK id in session(), since two pages can be open and I get wrong PK id – Albert D. Kallal Aug 06 '21 at 20:00
  • 1
    You need to use out-of-process session state. [Pros and Cons of using ASP.NET Session State Server (instead of InProc)?](https://stackoverflow.com/questions/2714288/pros-and-cons-of-using-asp-net-session-state-server-instead-of-inproc) – Andrew Morton Aug 06 '21 at 20:01
  • I also was not aware that session() persists if the user exits the site - it should start out fresh - but as I noted, it REALLY should not matter, and such lingering session() values should never matter in your code anyway. But, as noted, ViewState is per page, (client side), but session() is global to one user. So, session() really can't be used for things like say click on a girid, and then jump to next page with that PK id in session(). You can do this, but on page load I transfer that session value(s) to viewstate, and thus my pages can work if more then one browser (or tab) is opened. – Albert D. Kallal Aug 06 '21 at 20:02
  • The session variable I'm using specifies which role a user is using for a particular session in the application, so I don't think ViewState would work well for that. I'll look into out-of-process session state. – jbrown7061 Aug 06 '21 at 20:09
  • Also, you probably want to change the "Recycling" parameters in the "Advanced settings" for the application pool for the web site in IIS Manager to recycle at a fixed time instead of at an interval. – Andrew Morton Aug 06 '21 at 20:09
  • @jbrown7061 Remember to set the "ASP.NET State Service" service to "Automatic Start". – Andrew Morton Aug 06 '21 at 20:12
  • Well who is logged on and doing what can always be had from the secuirty/role providers such as the logged on user. I fail to see why session() would then matter. And even worse I fail to see how such data persisting for a single user would matter? Session() is per user - But then again, if you use session() for things like say a PK row selection, then session() can be a problem since if the user has two web pages open to buy a house they are looking at, and you use session() for that PK value, then two pages are open, but only one PK value in session exists (hence why I suggest view state). – Albert D. Kallal Aug 07 '21 at 18:31
  • I am only suggesting to use ViewState for things that are resoved per page, and not necessry per user. Things like logon ID - they can be session(), since that information applies to all web pages they would have open. But for a single page - selecting of a row and such values that are per page, and not necessary per user, then you need to use ViewState for such pages. But if the values don't care about per page, then again session() should be fine - even if it persists when they exit the web page and come back (as noted, session is re-set when this occurs, but should not matter anyway) – Albert D. Kallal Aug 07 '21 at 18:34

0 Answers0