On Tuesday, April 23, 2013 4:00:11 AM UTC+2, 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).
ok, that's consistent with what observed > > 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). > turning to the old system makes me "sick & sad" . Creating a session only when it's needed is "the right thing to do"© . > > 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). > wouldn't a simple note in the book close the deal ? This happens only when there is no session file and the user concurrently requests something that needs to be saved to session. In any case, leaving up to the developer is the right choice. > > 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 > it's a problem "in general": either you want concurrency or you want locking..... can we even theoretically solve that problem ? I don't think so. -- --- 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 web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
