Squeak
  links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
About optimistic locking
Last updated at 5:35 pm UTC on 16 January 2006
Locking of objects is done in multi-user systems to preserve integrity of changes; so that one persons changes do not accidently overwrite anothers.

Optimistic locking

With optimistic locking, you write your program under the assumption that any commit has a chance to fail on account of at least one the objects being committed was changed by someone else since you began the transaction.

Optimistic locking offers reduced contention and higher performance than pessimistic locking. It also avoids deadlocks.

Pessimistic locking

In pessimistic locking, your program must explicitly obtain a lock on one or more objects before making any changes. This prevents any other session from making changes to those objects, so you can be more assured that committing the transaction will succeed.

Once changes are complete, the objects are unlocked so that others may make changes to them.

Pessimistic locking increases contention because objects are tied up for longer periods. Locking objects also imposes more work on the database server. When there is a conflict, sessions have to "get in line" to wait for an object to become unlocked. These sessions may, themselves, already have other objects locked up while they're waiting. If any of these objects needed by a session are farther ahead in line then you will have a "deadlock," which can be difficult to manage. ok