On Tuesday, April 5, 2011 12:25:13 PM UTC-4, David Warnock wrote: > > Jonathan, > > > This policy is okay, but not good for reasons argued above. It is >> > better not acquiring a lock unless you need one than to keeping a lock >> > unless you don't need it. >> >> My question is: in your locking policy above, what's the purpose of >> locking at all? > > > I wonder whether it would be possible to have a strategy as follows: > > - default behaviour stays as now (for compatibility) > > - an additional decorator is added to specify that this method should be > called without locking the session > I think the session is locked (if it exists) by the framework *before* any application code is executed, so web2py would have no way of knowing not to lock the session. As an alternative, I suppose there could be some kind of configuration file that the framework could read to determine whether to lock the session, conditional on the particular controller and/or function in the request. A current workaround could be to create a model file that gets executed first (e.g., 00_sessions.py) and have it unlock the session for a pre-specified set of controllers/functions. The unlocking would probably happen within milliseconds of the initial locking by the framework, so there would be minimal unnecessary locking.
> To allow fine grained session control for long running methods maybe we > could have the following method added > - reload_session (to reload the session. If we have not locked the session > then it might have been changed by another process since we loaded it. This > will refresh our copy so the values are up-to-date. If another process has > the session locked then we will pause here until the lock is released. This > method should have an argument to control whether the session is locked when > it is reloaded so then we can safely modify the session knowing it is both > up-to-date and locked). > Isn't that what session.connect() does? Anthony
