> * It seems that web2py needs sessions most of them when users are logged > in, if we're following recommendations for signed URLs etc. Also, disabled > sessions means no CRUD according to the book, which presumably also rules > out SQLFORM & family. >
SQLFORM does not require the session, though without it, you lose CSRF and duplicate submission protection (though the latter can be handled via JS on the client side). > So session.forget is a specific circumstance which is perhaps not so > common. > > * if a session is not changed, there is no write penalty, but this is only > relevant whenever session.forget could have been used anyway. > Correct, session.forget() is not necessary when you're not changing the session, because the session won't get written in that case anyway. However, session.forget() can still speed things up a bit -- without session.forget(), web2py needs to hash the session in order to detect a change -- this step is skipped if session.forget() is called. Also, note that session.forget(response) also unlocks the session file in addition to forgetting the session. Locked session files block additional requests within the same session, so unlocking can be beneficial in addition to forgetting. > * Sessions can be stored on the filesystem (default) or in a database. > the file system imposes locking which can block web2py if a user is doing > several session-altering requests at the same time, most likely because of > ajax use. > database sessions don't lock, which is an advantage. > If multiple requests are *writing* to the session, then blocking is an advantage, as it prevents race conditions. > Or the ajax calls could do session.forget (but I suppose this wouldn't > work if the ajax calls involved signed URLs) > session.forget() just prevents the session from being written, but it doesn't clear the session object that is part of the current request, so the items in the session can still be read after session.forget() has been called. So, an ajax call involving a signed URL should still work. > The ajax situation (avoiding locks) seems the biggest advantage to > database sessions, unless you have access to a database which strongly > outperforms the filesystem. > Again, this depends on whether or not you need the locking. And even with file based sessions, you can just use session.forget(response) to unlock. Anthony -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- 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.
