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.
