Applications using two-phase locking cannot scale well

Though two-phase locking is a widely used algorithm for serializability in databases, the reason it hasn't been used extensively is performance. Transaction throughput and response times are significantly worse under two-phase lacking than under weak isolation.

There is a performance hit because of two reasons:

• Overhead of acquiring and releasing locks (more frequently than when using Explicit Locks)
• Reduced concurrency because of transactions waiting for other inflight transactions to complete

These issues can cause widely varying response times, even for OLTP applications that keep transactions short. A single transaction waiting in queue for access may, in turn, block all other transactions waiting to access the same object, resulting in a line-up. Even when applications and databases have reasonable defaults for aborting long-running transactions, the time limit is untenable for real-time applications.

Databases perform significantly worse under heavy load when there is high contention for object access. Deadlocks can occur more frequently under 2PL serializable isolation, depending on data access patterns. So one slow transaction that accesses a lot of data and acquires many locks may bring the entire system down. Plus, transactions that are aborted need to be retried again, adding to the load of the database.

These concerns make 2PL impracticable for most applications, which are data-intensive or service a high number of concurrent users.