Salesforce Record Locking and Concurrency – Salesforce Things You should Know

If you build on Salesforce long enough, you will hit a lock. This post explains how Salesforce Record Locking and Concurrency work, why you see UNABLE_TO_LOCK_ROW, and how to write code that behaves correctly under load. Why Salesforce locks records In a multi user system, two updates on the same record at the same time can corrupt data. To prevent that, Salesforce uses exclusive row locks: When a transaction modifies a record, it takes a lock and holds it until the transaction ends. Another transaction that tries to update the same record waits for about 10 seconds. If the lock is not released in time, Salesforce throws UNABLE_TO_LOCK_ROW. Reads operations are different. A concurrent read operation sees the last committed version, not the in progress changes. That is normal isolation, meaning uncommitted changes are never visible to other transactions. Reads vs writes in plain language Writes (DML) take a lock. Other writers wait. Reads (plain SOQL) do not lock and do not wait. They r