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 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). Dave -- Dave Warnock: http://42.blogs.warnock.me.uk Cycling Blog: http://42bikes.warnock.me.uk
