Optimistic concurrency control: Difference between revisions

Revision as of 11:21, 9 February 2020

Revision as of 10:18, 5 March 2020

Line 15:

The [[Stateless server|stateless]] nature of [[HTTP]] makes locking infeasible for web user interfaces. It's common for a user to start editing a record, then leave without following a "cancel" or "logout" link. If locking is used, other users who attempt to edit the same record must wait until the first user's lock times out.

[[HTTP]] does provide a form of built-in OCCtesting testing testing: The GET method returns an [[HTTP ETag|ETag]] for a resource and subsequent PUTs use the ETag value in the If-Match headers; while the first PUT will succeed, the second will not, as the value in If-Match is based on the first version of the resource.<ref>{{cite web | url = http://www.w3.org/1999/04/Editing/ | title = Editing the Web - Detecting the Lost Update Problem Using Unreserved Checkout | work = W3C Note | date = 10 May 1999}}</ref>

Some database management systems offer OCC natively - without requiring special application code. For others, the application can implement an OCC layer outside of the database, and avoid waiting or silently overwriting records. In such cases, the [[Form (web)|form]] includes a hidden field with the record's original content, a timestamp, a sequence number, or an opaque token. On submit, this is compared against the database. If it differs, the conflict resolution algorithm is invoked.