Caching and session variables when calling page with variables

[nlights]

Here's a scenario that is giving me conniptions today:

• User calls an AW5 page like this: www.somepage.html?familyid1=4&eventid2=5
  
• The page loads, user types some info and submits the page, at which point the database is updated with familyid1=4 and eventid2=5. Life is good.
  
• User exits the page and loads a different page within one minute or so (the page is different but the parameter names are the same: familyid and eventid). In this example the second call uses a different "eventid" parameter value, such as: www.someOTHERpage.html?familyid1=4&eventid2=6
  
• The page loads, user types some info and saves the page. However, at this point the database is updated with familyid=4 and eventid=5 (rather than eventid=6.) Life is bad.
  
• If the user waits a few minutes between the two calls to the different pages that have the same parameter names but different values passed in, the database is updated properly, in this case familyid=4 and eventid=6. Life is good again, sort of. Ditto if the user closes and restarts the browser between the two calls.
  

So clearly there is some caching going on here, and the second page takes some liberties with parameter name/value pairs when multiple pages are called in rapid succession -- in this case, it appears to use the previous eventid value (5) rather than the current one (6). Is there a way around this? Can my life be good again?

[-Jinx-]

Re: Caching and session variables when calling page with variables

I had a similar problem with pop-up windows caching variables. I had to put in code to delete the window, if it exists, before opening a new one. This might be a similar problem. Can you delete the variables after submit?

[[email protected]]

Re: Caching and session variables when calling page with variables

It does sound like some sort of timing issue but this is a hard one to answer without seeing it first. Let me see if I can think up a good solution for you.

[nlights]

Re: Caching and session variables when calling page with variables

Thank you for your responses. I figured a workaround: I'll just use different parameter names for the different web pages, along these lines:

www.somepage.html?familyid1=4&eventid2=5

www.someOTHERpage.html?familyid1B=4&eventid2B=6

This is a bit of a special case in that these pages tend to be called one right after another (it's a sequence thing.)

Deleting the variables after submit doesn't work too well because the first page in the sequence has a list with separate submit -buttons for each list item, and the users may need to submit more than one item while they are on that page. Asking people to click <exit> after they are done submitting the list items (and deleting the variables at that point) is a possibility, but more likely than not many people would probably ignore the request or just forget about it. As the NRA would say: "People are the problem."

Deleting the window doesn't work too well, either, because most people just open a new tab when they go to this site (they do it by clicking a link in an email, which tends to open a tab in an existing window automatically), so if I close the browser window, that'll close other tabs as well, and people don't like that (they will actually probably just click NO to the Close All Tabs -prompt at the browser.)

[Steve Wood]

Re: Caching and session variables when calling page with variables

It cannot be a timing issue or cache. If your URL has parameters, the parameter values provided will be available on the page as request.variables.

[-Jinx-]

Re: Caching and session variables when calling page with variables

In case it helps, here is a link to the thread that Sarah helped me out with my window problems:
http://msgboard.alphasoftware.com/al...-jinx-+caching

[nlights]

Re: Caching and session variables when calling page with variables

Thanks, Steve.

I don't know, however, how else to explain it. If two pages get called with separate URL links BUT same parameter names AND different parameter values, I can clearly see that the previous parameter values for the same parameter names get used in the second call, while the new values are unceremoniously ignored. Not so if a person waits for a few minutes between loading the two different pages. Walks like a cache/timing issue, squawks like a cache/timing issue... I'm not saying that this is necessarily an A5 problem, by the way -- it is probably just the Way of the Wacky Web. Annoying, nevertheless.

FYI, I turn request variables into session variables in the landing pages.

[nlights]

Re: Caching and session variables when calling page with variables

Thanks for the link, Jinx. I looked through it but didn't see how exactly it would apply in my situation. It's good to know for future reference, though (assuming THE BRAIN can retain this particular tidbit until then...)

In case it helps, here is a link to the thread that Sarah helped me out with my window problems:
http://msgboard.alphasoftware.com/al...-jinx-+caching

[Steve Wood]

Re: Caching and session variables when calling page with variables

hard to tell for sure from what you provided, would need to see the code on that page, how it is used, and everything else involved. But I believe I am also quoting Lenny when I say the URL parameters are not cached.

[nlights]

Re: Caching and session variables when calling page with variables

Thanks, Steve. I don't think the parameters per se are cached, just the session variables (that start their lives as parameters, but are turned into session variables as the page loads.)

Again, I have proven empirically that this is what actually happens:

• First URL call turns request variables (fid=1&eid=2) into session variables (fid=1, eid=2.)
• Second URL call turns request variables (fid=3&eid=4) into session variables (fid and eid.)
• If the second page is called within 1-2 minutes of the first page call, the session variables in A5 code that follows are still fid=1 and eid=2, rather than 3 and 4 .
• If the second page is called more than 1-2 minutes after the first page call, the session variables in A5 code that follows are fid=3 and eid=4, as they should .

If the two calls are made in rapid succession, the database ends up getting scrrrrewwwedddd up big time, because the data that users enter during the second call ends up getting written into wrong data slots (eid is a primary key and fid is a foreign key.) Luckily for me, the way my application happens to work is that it uses the same eid -values on both calls, and because of that I can go into the database and straighten out this mess after the fact. However, if both parameter values happened to be different during the two calls, I just simply couldn't repair the data.

I never saw this before because my app didn't call for this type of rapid sequential page calls before. But now that it does, the monster has surfaced and started trashing my poor database.

Again, my interim solution to this problem is to always use different parameter names for different URL calls for different pages. This works as long as the same page doesn't get called in quick succession with different parameter values. In that case, my parameter names remain the same during both calls (because the same page is called), and my data ends up getting irrevocably hosed.

[Steve Wood]

Re: Caching and session variables when calling page with variables

irrevocably hosed

Wasn't that a band in the 70's? I am pretty sure it will come down to how you are using the request.variables on the page, or consumed by a grid, etc. The "timing" issue may be your session timeout, though unlikely it is that short. Or, the "timing" is smoke and really something else happens during that time frame, like they visit another page that does something to the session vars. If you want to PM the A5W page in question, maybe I will spot something.

[nlights]

Re: Caching and session variables when calling page with variables

Steve --

Thank you for your offer to take a look, that's really very generous of you. I'm super busy right now, but I'll send it to you sometime tomorrow. Would be nice to know if there is something I did/something I can do to create/solve this situation.

Cheers!

Pertti