Re: Challenge: Sessions & Frames

I understand your point, but I'm not sure that you understood mine. (see below) "Chris Shiflett" <shiflett@php.net> wrote in message news:20040126053345.65324.qmail@web14301.mail.yahoo.com... > --- Jonathan Hilgeman <phpnews@sitecreative.com> wrote: > Regardless of what you mean by that, it should be clear that nothing > except client-side scripting is going to happen until your browser makes > another request. PHP is sitting on the server, twiddling its thumbs. Now, > if one of these browsers requests a new URL, PHP can use the session > information in generating the response, but it can do nothing for the > other browser windows. Does this make sense? > > Basically, all of the frames will share the same session, simply because > it's the same browser sending each request. Well, at the beginning, all frames share the same session. This is the desired effect, sort of like 3 trains all hooked together, running on parallel tracks. And it works great for a while. The problem I'm having is that one or even two of the tracks will (at random times) curve away and now instead of the 3 trains being grouped together, they're all running on different tracks. And sometimes Train 1 and 2 stay in sync, while Train 3 goes off to la-la-land and decides to start its own session. I -do- use Javascript, client-side scripting to refresh the top frame when some data has changed and I want the top frame to re-read it. But SOMETIMES refreshing it will just cause the shared session to split (which is the main problem I'm having). This is what I don't understand. If each frame has code to start a session and all requests (to the parent, top frame, and bottom frame) are being sent by the same browser window, then I don't know how/why they decide to randomly start their own sessions sometimes. It's almost like one frame "forgets" that it was already in the middle of a session and starts up a new session for itself. I thought that maybe the cache was expiring, but it's just too soon for that to happen - this can happen within the first few seconds of being logged in. I also set session_cache_expire to 720 minutes (overkill, but I was desperate), and that didn't help. It's ALMOST like my browser isn't taking cookies, but I know for a fact that it is (especially since every once in a while, everything can stay in sync and work properly for a few minutes). I'm considering just scrapping the reliance on cookies and forcing the scripts to pass the PHPSESSID through every link, so that any time a train might decide to go off and do its own thing, I'll be yanking it back so that it stays consistent with the other trains. I figure that as long as I dictate what session to use, I won't have this problem. But that would be a real pain to have to go back and make sure all links are modified and working correctly to pass this variable (I have to worry about the 255-character limit on the GET query string, because some of my query strings get long when performing searches on the site).