Locking
Locking is used to prevent dirty reads (reading data that hasn’t been committed) and non-repeatable reads (reading data that gets deleted by another transaction before the one reading is finished).
Optimistic
Optimistic locking will lock a resource when committing the transaction. Optimistic locking will save the state of the data at the first access. As such, in optimistic locking you have the possibility of concurrent access. If an optimistic operation is to be performed, before the operation the initial state is compared to the current state. If there is a discrepancy (the resource has been modified in the meantime), the transaction is not committed.
Optimistic force increment
For versioned objects, this will increment the object’s version number. On non-versioned objects an exception will be thrown.
Pessimistic
Pessimistic read
For repeatable reads, used to ensure that data isn’t updated between reads. It is a shared lock meaning different processes can perform read operations (no write operations are permitted).
Pessimistic write
An exclusive lock which forces serialization of updates. Where optimistic locking only saved state, here it is locked to prevent transaction failure/deadlock in cases where this would happen with concurrent operations.
Pessimistic write force increment
Analogous to its optimistic counterpart, a pessimistic write that updates the object’s version. Throws an exception for non-versioned objects.