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 !!!!!!!!!!!!!!!
+ 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:
def foo():
session.forget(response)
time.sleep(60)
However, what this function "foo" does is simply sleeping. In other
words, it locks up session for nothing.
Clearly, session is a critical piece of data and it ought to be
synchronized carefully. But I think the current policy of locking
session can be improved.
Instead of "locking by default unless explicitly forgetting", we
require locking *only if* sessions is saved/written/modified.
Processes that do not modify sessions should not lock it; as did "foo"
above, case in point. It seems currently the semaphore is placed
right at the beginning of the function, even though the better thing
is placing it just right before session is modified and saved.
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.
Further, processes/functions that do not modify sessions should be
allow to read sessions.
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.
