Many, if not most, multiuser applications that use indexed files use pessimistic concurrency (record locks) to avoid having two users attempt to update a record at once, thereby losing one of the updates. The name pessimistic concurrency is used because record locks are often obtained and held while a user is making changes.
If pessimistic concurrency (i.e. normal record locks) is used in a web services environment, the service program must be stateful. That is, the service program must continue to exist while the web client is acting on the data, waiting for the web client to release the lock, or to time out. In reality, though, it is often the case that the web client may never return (consider JavaScript in a browser when the user closes the browser window).
The answer to the operation difficulties in a web service environment of pessimistic concurrency is the use of optimistic concurrency. In optimistic concurrency, the contents of a record are recorded or remembered at the time a record is read. Then, when a user desires to change or delete the record, the original contents of the record are compared to the current contents of the record. If the contents have not changed, the update of delete operation is completed. If the contents have changed, the user is notified and the change is not made.
tutorial2 demonstrates a tactic for detecting a change in record contents without storing a copy of the original contents of a record. A message digest (also known as MD5) is computed when the record is originally read, and is sent to the client along with the record contents. (One of the characteristics of a message digest is the fact that changing a single bit in the message - in this case, the record contents - will cause a change in the message digest.) When the client desires to update or delete the record, the original message digest is sent as one of the input parameters of the request. As part of processing the update or delete request, the server first reads the record with lock, recomputes the message digest and compares the computed digest to the digest sent by the client. If the digests are equal, the record has not changed and the request is completed. If the record has changed, it is unlocked and the client is notified that the record contents have changed. (Note that the -Cr option must be used to compile the program that computes the message digest.)