Postback erases web control text

Hi all.

I'm having a problem with a postback issue and I think it's cache related.
Here's my setup:

I have a web site that has a signup section. This has simple things like
name, age, birth date, etc. When the user visits this page for the first
time, a person's data object that is used to store the user's name, age,
birth date, etc. is created and stored in session. On the first visit to this
page, the object is empty. Whenever the user posts back to this page, any
text from the text boxes is stored into the person's data object and the
session variable is updated.

There is a drop down control which causes the page to automatically post
back to itself and that's the year of birth drop down list. If the user
selects any year between 1993 and 2007, the page posts back to itself and a
new text box control appears for the email address of the person's parent (we
have to monitor minors 14 and under).

My problem is that sometimes when the year of birth drop down list is
changed, all the text in the other text boxes is erased. I've gone through
the code a lot and I think this is a caching issue. I can't find anything
wrong with how the code works and I don't see any way that the code is
erasing the session variable. This leaves me to believe this is a caching
issue. Does anyone know how to check caching settings in the web.config file,
app.config file, or anywhere else?

Re: Postback erases web control text

JP:

If IIS was reset in the middle of the session, you might have something like
this. Have you happened to check your app pools and see what the recycle
settings are set to? If not, that might be a place to look. Assuming that's
not the issue and that your session isn't timing out, I'd look to the code.
Most problems with IIS would result in null values being inserted not empty
strings. If you haven't done so, look under the App Pools node in IIS Admin
and verify your settings there.

Specifically, are you wrapping each attempt to get/set the Session variables
in properties? If so, what are you doing if you detect a null session
variable? Are you setting the value to an empty string? If not, it's a
good idea to do so as opposed to accesing them directly, for the same
reasons you shouldn't touch private member variables from outside of the
class ( a bit of an oversimplification here but valid in most cases). You
can put a logging statement in the Set Accessors and then run the app and
see what happens. If you can do it predictably by a sequence of actions,
I'm inclined to think it's the code somewhere. You could add a Debug
Assertion in the set accessor as well and verify you're not setting the
value to string.empty.

It probably sounds like I'm blowing off the issue of caching or something
with IIS - it's just that in my personal experience, behavior like this is
almost always b/c I did something and didn't realize it. Either i've
overlooked something on the PostBack code or I have an If i'm overlooking or
early on in development, my exception handling is doing something funky b/c
I haven't really implemented it as well as I should have. If you are
accessing the Session variables outside of properties, then you're in a
situation where you effectively have global variables and all the problems
that come with them and that makes it really hard to isolate. if you have
properties wrapping them, then you can stick a logger statement in there,
run through the steps that cause the problem and see what is happening and
when. Another similar approach is to create a BasePage that contains the
session variables that you use from one page to another. You can have a
global base page and then inherit from it for each group of pages that uses
the same values if you want that level of granularity. Or you can just use
one. But by creating properties in a base page, you can centralize your
null checks and validation for the get/set operations and 'know' that
nothing else is changing it. In this case, b/c you have a data object,
doing this might be too much rework so you could just modify your data
object if you're not doing it already. I only keep harping on this b/c in
most cases where you have session weirdness, you usually end up with nulls.

Also, are you specfically caching anything? I guess I should have asked
this first but are you using the ASP.NET caching mechanism explicitly? If
so, have you checked how frequently it's being invalidated? To that end,
are you using cookies and possibly overwriting the values? Similarly, are
you using ViewState? Is it enabled for the controls?
"JP" wrote in message
news:1043ADEF-1AD4-4560-8477-BBCE1A4D1C8C@microsoft.com...
> Hi all.
>
> I'm having a problem with a postback issue and I think it's cache related.
> Here's my setup:
>
> I have a web site that has a signup section. This has simple things like
> name, age, birth date, etc. When the user visits this page for the first
> time, a person's data object that is used to store the user's name, age,
> birth date, etc. is created and stored in session. On the first visit to
> this
> page, the object is empty. Whenever the user posts back to this page, any
> text from the text boxes is stored into the person's data object and the
> session variable is updated.
>
> There is a drop down control which causes the page to automatically post
> back to itself and that's the year of birth drop down list. If the user
> selects any year between 1993 and 2007, the page posts back to itself and
> a
> new text box control appears for the email address of the person's parent
> (we
> have to monitor minors 14 and under).
>
> My problem is that sometimes when the year of birth drop down list is
> changed, all the text in the other text boxes is erased. I've gone through
> the code a lot and I think this is a caching issue. I can't find anything
> wrong with how the code works and I don't see any way that the code is
> erasing the session variable. This leaves me to believe this is a caching
> issue. Does anyone know how to check caching settings in the web.config
> file,
> app.config file, or anywhere else?

Re: Postback erases web control text

I'm using Windows XP and my version of IIS is 5.1. I don't think the app pool
feature is something that is available in 5.1. I checked the web for some
help on it, and I believe version 6 supports this feature.

I did a thorough debugging of my code and there is no code that overwrites
my values in the session object. I checked every possible conditional branch,
every single inherited page that messed with execution, master pages and
still nothing.

I'm not using cookies. This login process is stored entorely in the session.

As far as caching is concerned, I haven't specified anything to specifically
cache data or clear the cache.

My session variables are being validated by "if session["variable"] exists,
do something" so I'm not ever getting null reference exceptions.

When I do my debugging, I go from page 1 to page 2 and the session is
totally cleared. It's really baffling.


"W.G. Ryan" wrote:

> JP:
>
> If IIS was reset in the middle of the session, you might have something like
> this. Have you happened to check your app pools and see what the recycle
> settings are set to? If not, that might be a place to look. Assuming that's
> not the issue and that your session isn't timing out, I'd look to the code.
> Most problems with IIS would result in null values being inserted not empty
> strings. If you haven't done so, look under the App Pools node in IIS Admin
> and verify your settings there.
>
> Specifically, are you wrapping each attempt to get/set the Session variables
> in properties? If so, what are you doing if you detect a null session
> variable? Are you setting the value to an empty string? If not, it's a
> good idea to do so as opposed to accesing them directly, for the same
> reasons you shouldn't touch private member variables from outside of the
> class ( a bit of an oversimplification here but valid in most cases). You
> can put a logging statement in the Set Accessors and then run the app and
> see what happens. If you can do it predictably by a sequence of actions,
> I'm inclined to think it's the code somewhere. You could add a Debug
> Assertion in the set accessor as well and verify you're not setting the
> value to string.empty.
>
> It probably sounds like I'm blowing off the issue of caching or something
> with IIS - it's just that in my personal experience, behavior like this is
> almost always b/c I did something and didn't realize it. Either i've
> overlooked something on the PostBack code or I have an If i'm overlooking or
> early on in development, my exception handling is doing something funky b/c
> I haven't really implemented it as well as I should have. If you are
> accessing the Session variables outside of properties, then you're in a
> situation where you effectively have global variables and all the problems
> that come with them and that makes it really hard to isolate. if you have
> properties wrapping them, then you can stick a logger statement in there,
> run through the steps that cause the problem and see what is happening and
> when. Another similar approach is to create a BasePage that contains the
> session variables that you use from one page to another. You can have a
> global base page and then inherit from it for each group of pages that uses
> the same values if you want that level of granularity. Or you can just use
> one. But by creating properties in a base page, you can centralize your
> null checks and validation for the get/set operations and 'know' that
> nothing else is changing it. In this case, b/c you have a data object,
> doing this might be too much rework so you could just modify your data
> object if you're not doing it already. I only keep harping on this b/c in
> most cases where you have session weirdness, you usually end up with nulls.
>
> Also, are you specfically caching anything? I guess I should have asked
> this first but are you using the ASP.NET caching mechanism explicitly? If
> so, have you checked how frequently it's being invalidated? To that end,
> are you using cookies and possibly overwriting the values? Similarly, are
> you using ViewState? Is it enabled for the controls?
> "JP" wrote in message
> news:1043ADEF-1AD4-4560-8477-BBCE1A4D1C8C@microsoft.com...
> > Hi all.
> >
> > I'm having a problem with a postback issue and I think it's cache related.
> > Here's my setup:
> >
> > I have a web site that has a signup section. This has simple things like
> > name, age, birth date, etc. When the user visits this page for the first
> > time, a person's data object that is used to store the user's name, age,
> > birth date, etc. is created and stored in session. On the first visit to
> > this
> > page, the object is empty. Whenever the user posts back to this page, any
> > text from the text boxes is stored into the person's data object and the
> > session variable is updated.
> >
> > There is a drop down control which causes the page to automatically post
> > back to itself and that's the year of birth drop down list. If the user
> > selects any year between 1993 and 2007, the page posts back to itself and
> > a
> > new text box control appears for the email address of the person's parent
> > (we
> > have to monitor minors 14 and under).
> >
> > My problem is that sometimes when the year of birth drop down list is
> > changed, all the text in the other text boxes is erased. I've gone through
> > the code a lot and I think this is a caching issue. I can't find anything
> > wrong with how the code works and I don't see any way that the code is
> > erasing the session variable. This leaves me to believe this is a caching
> > issue. Does anyone know how to check caching settings in the web.config
> > file,
> > app.config file, or anywhere else?
>
>
>