You must not have ever worked with a non-bitty multiuser database application. The "view" presented to the user on the Cathode Ray Tube (or the Teletype machine) is not the "ongoing" state of affairs, it is "the truth" as it existed at the exact instant that it was claimed to have existed. The fact that the bag-of-water reading the Teletype printout takes twenty minutes to read the output has zero relevance on the fact that, at the instance the teletype printed the data, in represented the exact truth at that instant. Not some programs "impression" or "wishful thinking" of what the state of truth was at that instance -- but the actual hard-boiled truth. If the bag-of-water wants a subsequent printout of the truth as it exists at some later time, then the bag-of-water can request that another printout of the truth be obtained which reflects the truth at the time of the request. If the bag-of-water wishes to change the "state of truth" from state A to state B by modifying C, then the very first step is to ensure that state A is still the truth before applying C to arrive at state B. This is concurrency management 101. Actually, I think it is concurrency management pre-school (that is, it is a foundational concept) and as such no education is possible without a grounding in the foundational concepts. This is the reason so many people find concurrent programming hard and why many attempts at concurrent programming fail (and this includes things like multithreading). Great effort is spent addressing symptoms rather than the root cause.