>>My question is: in your locking policy above, what's the purpose of locking >>at all?
If you don't lock during writes (e.g. when updating the counter), two writes might happen "simultaneously" and cause inconsistent results. Essentially, this is what I think how SQLite works: concurrent reads are allowed, but only 1 write at a time. >>> write-2.update(counter = counter + 1, a = "hello") >>> write-1.update(counter = counter + 1) >>Unless by "update" you mean that the agent re-reads the session file under >>the write lock, the above sequence will only increment counter once. Yes, "re-reading" if you want to think of it like that. The point here is changing session variables should be done atomically (meaning a lock is acquired) and quickly. If you do it like this, "update" is an atomic synchronized operation. This is clearly better than having the whole controller function as an atomic operation (which is currently the case).
