On Apr 5, 2011, at 8:26 AM, VP wrote: > > >> read-1 >> read-2 >> write-2 >> write-1 >> >> ...so any changes #2 makes are lost. > > I think this sequence is okay, as long as the write's are atomic and > they use up-to-date information. > > It would be undesirable for read-1 to extract a variable and to update > it with write-1. But if write-1 manipulates variables atomically, > then we don't problems. Consider a simple example with a counter > like this. > > > a = read-1 > b = read-2 > 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. > > We don't have any problem. I think databases automatically take care > of these synchronization. Even if process 1 does something with "a", > after process 2 modifies it. Conceptually, that should be okay. > Information process 1 gets is stale, but that's life. > > I don't think this is a problem either: > >>> A database ... would not automatically handle locking >>> while an application function is potentially manipulating the session (prior >>> to updating it in the database). >
