Wierd problem with session ending in ASP.NET 2.0 with VS ASP.NET Development Server

[Ken Varn]

When I am running my ASP.NET 2.0 application using VS.NET 2005 ASP.NET
Development Server, the session state seems to be getting lost at various
times without warning. I am not sure why this is happening. It is not
related to timeout because it occurs way before the default of 20 session
timeout setting.

One thing that I did notice that may be a key to this:

1. Place a breakpoint in Global.asax for session_end.
2. Run ASP.NET application using Visual Studio.
3. Go to a page that makes a SQL database update to a row in any table.
4. While debugger is running, load table data from table where row was
updated in step 3 using Visual Studio IDE.
5. Application will hit session_end breakpoint without doing any postback
from web page. (Why???)
6. At this point, the session variables in my running debugged page are
gone when it does a postback.

I am not sure if the info related above is related to why the session ends
on its own, but I was really confused as to how in the world I could hit my
session_end breakpoint when I did not do a postback to the web site at all.
I merely displayed some data using the Visual Studio SQL data viewer.

Anyhow, is there any explanation as to why session is disappearing before
the session timeout setting?


--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------

 

[bruce barker]

inproc session end anytime a site recycle occurs (memory limit, file
change, recompile, etc). most likely a file change in happening causing
a recompile, which ends all sessions.

-- bruce (sqlwork.com)

 

[Ken Varn]

inproc session end anytime a site recycle occurs (memory limit, file

change, recompile, etc). most likely a file change in happening causing
a recompile, which ends all sessions.

None of these areas were changed as far as I can tell, unless VS does
something in the background that I am unaware of. All I can say is that the
only time it seems to happen consistently is when I select "show table data"
in VS.NET while the app is running.


--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------

 

[Latish Sehgal]

Actually, even there is a file change, the current requests are served
using the existing site in memory, and all future requests use the new
recompiled site.
Did you try to enable tracing and analyzing that?

 

[aamirghanchi]

Actually, even there is a file change, the current requests are served
using the existing site in memory, and all future requests use the new
recompiled site.
Did you try to enable tracing and analyzing that?

I am having similar problem with session variable values set in an
aspx.vb page does not carry over across page postbacks. This started
happening in a newly converted app from ASP 1.1

 

[replytosury]

I am having similarproblemwithsessionvariable values set in an
aspx.vb page does not carry over across page postbacks. This started
happening in a newly converted app from ASP 1.1

I am also facing the same problem. I have an apsx page with two
buttons.
Click on first button session remains. When i click the second button
the session clears off all the keys gets cleared.

I even tried two buttons with absolutely no code written in the event,
but still behaves the same way.

Can any please let me know if you have any suggestions or comments.

Thanks

 

[Aamir Ghanchi]

I am also facing the same problem. I have an apsx page with two
buttons.
Click on first button session remains. When i click the second button
the session clears off all the keys gets cleared.

I even tried two buttons with absolutely no code written in the event,
but still behaves the same way.

Can any please let me know if you have any suggestions or comments.

Thanks

My problem was solved, but it was something other than session being
reset. see the last post on following link:

http://groups.google.com/group/[email protected]&rnum=2#21a4e0a6a0074fea