> > 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. >
> > 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 think it's a matter of policy. From the performance point of view, not locking on read is good. It is true that reading an unlocked session, might yield in stale information -- perhaps inconsistent . But I don't think there is much harm in that. There might be some issues if users of the same session are using highly interrelated session variables to make a decision. I think this use case is slim. Other than that, locking on read is a performance penalty. The use case is this. When a user is executing a long-running controller function, he won't be able to use other controller functions, unless he has to session.forget(response) at an appropriate place in the long-running process. There are many issues: (1) Clearly, not being able to use other controller functions while something is running, is undesirable, in terms of useability. (2) Sometime, it might be difficult AND/OR inconvenient to run the long-running function as a background process. To avoid (1), session.forget(response) must be placed at *appropriate* places. If the the long-running function is also extracting session information (e.g. form variables), he can only session.forgetting after getting out those information. (3) If a function takes 5 minutes to run, clearly something needs to be done. But there are deceptively dangerous cases when it takes 20 seconds to run. I am only guessing here, but I think a few programmers will avoid the extra work to be done (e.g. running as a background process), and just let users wait 20 seconds. It's only 20 seconds right? But i think it will accumulate to a bad user experience. == I think the policy is quite simple: you don't lock session, if you are only reading session variables. You lock only if you modify session certain variables; and you lock it immediately before you write, and unlock immediately before you write.
