On Sunday, April 3, 2011 10:42:17 PM UTC-4, VP wrote: > > i'm making a few observations as i'm debugging my app. They might > reflect my lack of understanding of how web2py works. Anyway, a few > thoughts > > + It appears session.forget() (as mentioned numerous times in the > book) should be session.forget(response). I have used > session.forget() for a long time, thinking it does what I wanted it to > do; it turns out that what I need is session.forget(response). If my > understanding is correct on this issue, I think the book ought to be > corrected !!!!!!!!!!!!!!!
Yes, that's a good point -- it's not very clear that you have to call session.forget(response) or session._unlock(response) to actually unlock the file. > > + I feel uneasy with the current way of session handling. This mostly > has to do with functions that take longer periods of time to run. > They lock up sessions. To get around this, it seems you have to > "forget" sessions at the right place. For example: Yes, you should "forget" at the earliest opportunity (maybe even at the top of the controller file if none of the functions use the session). > Instead of "locking by default unless explicitly forgetting", we > require locking *only if* sessions is saved/written/modified. You might also want to lock the session even if it is merely being read -- otherwise, if a second action writes to the session after a first action has read it in, then the first action will be working with a version of the session that is no longer up-to-date. > Typically, a long-running function spends its time mostly doing some > computation and not touching sessions at all. There is no need for it > to acquire the lock during its entire time of execution. I suppose it depends on the case. If the long-running function needs to read in the current session, then do some processing partly based on the session data, and then write to the session (or even just depend on the session data being up-to-date), then it needs to maintain the lock the whole time. > Further, processes/functions that do not modify sessions should be > allow to read sessions. Perhaps, but with the knowledge that the session might be updated by another function sometime after the session has been read in. > I could be wrong, but I think much of these synchronization can be > taken care of by storing sessions in a separate database. We can use > SQLite (for example), which locks only when being written to, but > allows large numbers of concurrent reads. A database would automatically handle locking during the brief period the session is written/updated, but it would not automatically handle locking while an application function is potentially manipulating the session (prior to updating it in the database). I suppose web2py could provide somewhat more fine-grained control over exactly when/if the session is read, locked, and written so you could optimize precisely depending on the use case. But I wonder how much gain there would be. As it is, you can unlock the session right at the beginning of your function, which would probably only be milliseconds after the lock was first acquired. And I suppose you could move the unlock even earlier if necessary, at the beginning of the first model file, possibly conditional on some request parameters (such as the controller and or function name). Anthony
