Benefits and drawbacks
Pessimistic locking has several advantages:■ Unlike optimistic locking, pessimistic locking does not require any schema changes.
■ It prevents a transaction from overwriting another transaction’s changes. By locking rows when they are read, a transaction can ensure that when it updates them later it will not overwrite another transaction’s changes.
■ It can be used to maintain read consistency in scenarios where a transaction reads from one table but updates another. A transaction can use SELECT FOR UPDATE to ensure that rows that it reads but does not update are unchanged when it commits.
■ It reduces the probability of deadlocks in databases that implement fully isolated transactions by locking rows when they read.
But again, there are some drawbacks and issues as well:
■ All potentially conflicting transactions have to use SELECT FOR UPDATE in order for pessimistic locking to work, which is potentially error-prone. For example, in the sendOrders/cancelOrder
scenario, if transaction B used a regular SELECT statement it would not block and would end up overwriting transaction A’s changes.
■ In databases such as Oracle where SELECT does not normally lock rows, the increased use of locks reduces concurrency and the overhead of maintaining many locks can reduce performance.
The increased use of locks also enhances the probability of deadlocks, which occur when two transactions are waiting for locks held by the other. Oracle automatically detects deadlocks and returns an ORA-00060 error to one of the participating transactions, which
can either roll back the entire transaction or retry the SQL statement that caused the deadlock. Other databases will signal a deadlock in a similar way.
■ Some databases have limitations on how SELECT FOR UPDATE can be used. For example, with Oracle, it can only be used at the top level and cannot be nested within another SQL statement.
Also, there are certain SQL features that cannot be used in conjunction with SELECT FOR UPDATE. These features include DISTINCT, aggregate functions, and GROUP BY. It cannot be used on certain types of views and nested SELECTs. This is a particularly important limitation
when an application uses a persistence framework since it has no control over the generated SQL.
■ An application that accesses the database using a persistence framework can only use pessimistic locking if the persistence
framework supports it. An application cannot implement pessimistic locking on top of a persistence
framework.
■ An application that uses pessimistic locking cannot use a process-level cache because it must access the database in order to lock the rows. Despite these limitations, pessimistic
locking is extremely useful in many situations.
When to use it
Pessimistic locking should be used when:
■ The database schema does not support optimistic locking because, for example, the tables do not have a version or timestamp column or contain values such as floats or blobs that cannot
be compared.
■ The application requires some degree of read consistency.
■ You don’t want to incur the overhead of serializable transactions.