Content deleted Content added
No edit summary |
|||
Line 7:
There are three phases in an OCC transaction:
<ol>
<li>'''Read''': The client reads values from the database, storing them to a private sandbox or cache that the client can then edit.</li>
<li>'''Validate''': When the client has completed editing of the values in its sandbox or cache, it initiates the storage of the changes back to the database. During validation, an algorithm checks if the changes to the data would conflict with either
Line 17:
</ol>
When conflicts are rare, validation can be done efficiently, leading to higher throughput than other concurrency control methods.{{Fact|date=February 2007}}
==Web usage==
The [[Stateless server|stateless]] nature of [[HTTP]] makes locking infeasible for web user interfaces.{{Fact|date=February 2007}} 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 expires.
OCC is a natural choice. It is simple to implement and avoids unnecessary waiting or silently overwritten records. Typically the [[Form (web)|form]] presented to the user includes a hidden field with the record's original content, a timestamp, a sequence number, or an
===Examples===
Line 31:
* The [[Ruby on Rails]] framework has an API for OCC. [http://api.rubyonrails.com/classes/ActiveRecord/Locking.html]
* Most [[revision control]] systems support the "merge" model for concurrency, which is OCC.
==See
*[[Opportunistic Locking]]
Line 39 ⟶ 38:
[[he:בקרת מקביליות אופטימית]]
| |||