Spin locks with variable time retry backoffs

I'd just requeue the job if you hit max retries:

try {
} catch(LocksService.MutexException e) {

At this point, your job will retry later. There's supposed to be a built-in delay for chained jobs, so this should provide the delay you're looking for.

Although not an answer per se, I wanted to post some performance stats based on a stress test using the spin lock and spin lock fallback strategy as answered by @sfdcfox. This is not a critique of the answer which was good but more of a cautionary tale should one pursue this route. YMMV


  • 50 queueable jobs (System.enqueueJob(..)) each launched in one stress testing transaction.
  • Each job enqueues on the same spin lock - that is, they all compete with each other.
  • Spin lock does a Select for Update and tries 10 times before abandoning
  • Each job does the same amount of work: (deserializes 1000 custom Json and then constructs/inserts 1000 Assets). That is, the work is "substantive".


  • 4 of the 50 queueables completed quickly and the rest were requeued by the spin lock backoff solution to another queueable. SFDC then reschedules these queueables (delaying up to 1 minute) and they (46) compete with each other again. This repeats itself over time until they all complete
  • Total elapsed time to get through 50 initial threads each trying to insert 1000 assets = 26 minutes. Three hundred nine (309) queueable retry jobs (!)


  • YMMV
  • A batch job would almost certainly be faster
  • Introducing some variable jitter delay between each spin lock retry would probably improve things but as the OP stated, it is not clear what a good delay would be that doesn't consume a scarce SFDC resource