When to use pessimistic concurrency?

Question

What are specific scenarios where pessimistic concurrency is used?

Answer 1

See this Wikipedia entry. If you need more specific information than this, post more specifics about your use case.

Answer 2

Yea sure, when you absolutely cannot have two people alter the same record at the same time. Banks do this the most.

Answer 3

What exactly do you mean by "when to use pess. locking" ?

If you're dealing with DBMS-managed data, you have no option. The DBMS uses it with every update, full stop, because the DBMS itself has no option too if it wants to assure data integrity.

Even MVCC-based systems (such as Oracle ?) have no option but to serialize activities using 2-phase locking to deal correctly with cases such as :

TX A starts, TX B starts ; TX A inserts ID 1 ; TX B inserts ID 1 ; TX A checks constraints ; TX B checks constraints ; TX A commits ; TX B commits.

If the constraint checking of A/B were allowed to ignore the insert of the same ID done by B/A, the database would end up violating the key.

Application-controlled locks had better only be pessimistic if you can be sure that they will not be left pending while the user is expected to type in some input or so (or while any activity is being carried out that potentially causes long delays). But that's an answer to the opposite question, "when NOT to use it".

EDIT

An indication for "When to use it" might be that in high-contention situations, you want "fail-fast" for whichever transaction "comes second". That ensures you that transactions that cannot be completed will not be hogging up too much resources, and those resources are available for faster completion (and thus also faster lock release) of wichever transaction "came first" and got the lock. Do realise, however, that you're increasing your chances of running into deadlocks too, and since the locks are application-controlled, it's up to you to resolve any deadlock.

Answer 4

Pessimistic concurrency should probably be used in situations where attempts at concurrent editing occur frequently, not as exceptional cases. Optimistic concurrency can cause jarring results for users when they are informed that their edits will not be saved, so it should be avoided when this is a normal occurrence.