Consider multiple processes are accessing a set of frequently updating records and they pick whatever matches certain criteria. They should lock those picked up records. So almost at the same time if any other process wants to pick their share, they should skip the locked ones, rather search for only new records that are not locked.

To lock records, we append For Update at the end of SOQL. So while a process is working now with such implementation strategy, what other processes would do pick other records skipping the locked ones?

1 Answer 1


The best way to handle high-frequency lock contention is to redesign the processes that are contending for the locks. There's a number of ways to do this:

  • Structure SOQL criteria so that most of the time the processes pick up records in a different order from one another, and build in retry logic that kicks in in the case of row locking.
  • Use Queueable chaining or batch process chaining to run overlapping processes in serial rather than parallel.
  • Schedule independent jobs such that most of the time they are able to complete processing before other jobs fire, and include retry logic.
  • Redesign record access so that certain locks don't get made at all (e.g., parent objects being locked). See the Record Locking Cheat Sheet for helpful details on this approach.

You can't query on "is a record locked" per se (you just attempt to lock it yourself) and attempting to set an "is locked" flag to query against is highly likely to cause difficult-to-debug race conditions.

If the lock contention is infrequent, retry logic is a good solution since that issue should be transitory.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .