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.
