Thanks Niphlod & Anthony - I'm glad we finally got to the bottom of this. I thought I was going crazy for a while there!
In the short term, I'll use Niphlod's trick of setting a dummy session variable to make sure the session is saved to disk. In the medium term, I vote for option 1 (always saving a session file, even if session is empty). As we've seen, the current logic can lead to unpredictable behavior (I still can't reproduce on my Ubuntu netbook - my best guess is that since it is old and slow, the ajax requests aren't overlapping). I'd say it is a little risky to rely on the developer to remember to add initialization code to every page that contains 2+ ajax components. It is easy to lose track of that sort of thing. On the other hand, allowing a developer to turn off sessions in general is a good optimization for those who know what they are doing. On Tuesday, 23 April 2013 03:00:11 UTC+1, Anthony wrote: > > The problem is that we made a change so that no session file is created at > all if this is a new session and the session remains empty. So, when the > index page is requested, no session file is created. Next, the form1 Ajax > request comes in, and because there is no session file, there is nothing to > read or lock. Meanwhile, the form2 Ajax request comes in, and again, there > is no file to read or lock. So, both requests start with an empty session > and add their respective formkeys to it. Next, the form1 request creates a > session file and writes its version of the session to it. Finally, the > form2 request opens and completely overwrites that session file with its > version of the session (which does not include the form1 formkey). > > What to do about this? I suppose one option would be to always create a > new session file when a new session is started, even if the session is > empty on the first request of the session (in the above example, an empty > session file would be created on accessing the index page). Some apps never > use the session, though, and would therefore have a bunch of unnecessary > session files (though I suppose you could still use the global settings to > turn off sessions). > > Another option is to leave it up to the developer to save something to the > session in the parent page request when the page contains multiple Ajax > requests that will be accessing the session. Maybe we could provide a > convenience method for this, such as session.save(), which would force > saving the file even if the session is empty (such a method might have > other uses, such as saving and then unlocking a session in the middle of a > request). > > Other ideas? > > I think there's a bigger problem with sessions in cookies and the db -- > they aren't locked at all, so you can get race conditions with them even > once the session has initially been saved. > > Anthony > > On Monday, April 22, 2013 4:59:16 PM UTC-4, Niphlod wrote: >> >> umpf.... I can't understand why this is not working "ok". >> >> The problem lies indeed in the fact that one ajax request overwrites the >> session, if the session file is not there yet..... >> I can only guess that the logic is failing to acquire a lock before >> creating the (new) file .... >> If a request has completed yet, hence the session file is present, all >> goes perfectly ok (it's probably the reason why nobody else ever noticed >> "the glitch", and why prepending a "session.hello = 'world'" to the index >> function makes all go smoothly, it actually creates the session file before >> the two ajax requests come in) >> can anyone testing this confirm this behaviour? >> steps to reproduce: >> - delete session file in the session/ dir >> - open the index page >> - session file ends up with one or another formname keys, never both >> - reload the page >> - session file holds both formnames >> - put session.hello = 'world' in the index() function before the return >> dict() >> - delete the session file in the sessions/ dir >> - reload the page >> - session file holds both formnames >> >> If this is indeed the behaviour, we narrowed it down to a "glitch" that >> happens in one case only: 2 concurrent requests comes in and there is no >> session file yet. >> We can start from there to coordinate efforts for the patch..... it's >> definitely not an issue with javascript. >> >> >> -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
