On Mar 17, 2011, at 10:44 AM, Anthony wrote: > Thanks. This is helpful. > > On Thursday, March 17, 2011 1:14:22 PM UTC-4, Jonathan Lundell wrote: > On Mar 17, 2011, at 9:45 AM, Anthony wrote: >> On Thursday, March 17, 2011 11:17:17 AM UTC-4, Jonathan Lundell wrote: >> On Mar 17, 2011, at 7:40 AM, Anthony wrote: >>> In the book under "Efficiency Tricks" it says: >>> >>> Set session.forget() in all controllers and/or functions that do not change >>> the session. >>> >>> Does this new change make it unnecessary to bother calling session.forget() >>> in most cases because sessions are no longer saved when empty or not >>> modified? >> There's at least one reason to call session.forget(): it unlocks the session >> file, allowing other requests in the same session to proceed. >> >> This won't be useful in all cases, since there may not *be* other requests >> pending. But it's a very lightweight call, so it doesn't do any harm. >> >> To unlock the session file, don't you have to call session.forget(request) >> or session._unlock(request)? Is plain session.forget() (with no arguments) >> still useful? > > session.forget(response), yes. > > With no arguments, no, offhand I think it's not useful, unless perhaps the > session actually got changed, in which case calling forget would > (effectively) discard the changes. > >> >> It would be helpful to get an understanding of exactly when session files >> are created, locked, written to, and unlocked as well as the exact effects >> and use cases for session.forget(), session.forget(request), and >> session._unlock(request), particularly in light of the recent change in >> trunk. >> > > I agree, though I think it should be in terms of an API spec rather than a > description of how it happens to work now, which might lock in accidental > behavior. > > At any rate, if a session file doesn't exist, it gets created lazily, at the > first point at which it would have to be written. So a series of requests > that never changes the session object will never create a session file. > However, since both auth and forms keep state in the session, a session will > be created when an auth form is used.
I should clarify that this is with Massimo's new optimizations, starting in 1.94. Earlier releases didn't defer creation of the session file based on whether it had changed.
