About optimistic locking
Last updated at 6:48 am UTC on 29 March 2018
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, commit error-handling code is written under the assumption the commit will fail if any one the objects being committed was changed by someone else since the beginning of the transaction. For example:
mySession commit:
[ "..update the model.." ]
on: aMagmaCommitConflictError
do:
[ : aMagmaCommitConflictError |
(ObjectDiffBrowser
on: aMagmaCommitConflictError result commitConflicts
labelled: 'Your changes to these objects were already updated, please review') openInWorld ]
aMagmaCommitConflictError result commitConflicts is a collection of detailed information about the specific objects in conflict. They are the objects this committing session tried to commit, but were already changed by another session. All of the other changes made by the committing session are still intact (in the image, not the database). So the other sessions changes are "merged" with this sessions changes (in memory), which may now either be committed (with or without adjustmnet) or, aborted.
Pessimistic locking
In pessimistic locking, the program must explicitly obtain a lock on one or more objects before making changes. This prevents any other session from making changes to those objects for the duration, so it is more likely committing the transaction will succeed.
Magma only supports optimistic locking. An application may employ its own pessimistic locking very simply with a boolean attribute.
