6

Cut to the chase: What causes UNABLE_TO_LOCK_ROW errors and what are best practices for avoiding them?

We built a great app that works solidly in development and testing. Today we launched to a team of 80 people who were all using the app and submitting forms simultaneously... and started getting UNABLE_TO_LOCK_ROW errors right and left. I realize that it's hard to diagnose what's going wrong without looking at our code, but it's a mammoth project. Each person was submitting new, original data -- they weren't working on or accessing the same records at the same time. What else could be going on?

CLARIFICATIONS

Some additional context to help with this:

  • The save routine saves a new Contact record, followed by a bunch of related information in other records. According to debug logs, the UNABLE_TO_LOCK_ROW error always hits during the very first DML operation - the Contact insert.
  • All of the Contacts are on the same Account. There are ~5000 Contacts on this Account; we've verified that there are no triggers or cross-object workflows affecting the Account.
  • In the debug logs, the DML error hits immediately after exiting the last before insert trigger on the Contact record, which is in a managed namespace (but we've gotten the managed code and reviewed it, and it appears to be no-op for the records we're inserting).
  • In successful saves, the next lines in the debug logs are for validation rules.
Improve this question
0

2 Answers 2

Reset to default
4

Some good questions to start asking, in addition to what Daniel mentioned, are:

Improve this answer
6
  • (1) No - we're inserting Contact records. All the contact records are children of them same account, but that's not a Master-Detail, there are no roll-up summaries, and I've verified that there are no triggers or cross-object workflow making changes to the account.
    – Benj
    Commented Apr 5, 2013 at 14:30
  • (2) All of the users are in the same role. The account in question is shared RO to this role, and all Contacts on the account are also shared RO (regardless of RecordType). A separare ContactSharingRule shares all of the contacts of the specific record type we're using to this role with RW access.
    – Benj
    Commented Apr 5, 2013 at 14:32
  • (3) Nope. For the users at this particular training, there were 5000 contacts on the account being used.
    – Benj
    Commented Apr 5, 2013 at 14:36
  • It sounds to me like a data skew issue. Even though you're under the 10K records, you have 80 users all hitting contacts under the same account at the same time. I would submit a case to Salesforce Help and make sure to highlight all of the things you mentioned in this comment.
    – greenstork
    Commented Apr 5, 2013 at 15:53
  • @Greenstock I just re-read that blog post and you're right, the show fits. Thanks much! Now to redesign the app...
    – Benj
    Commented Apr 5, 2013 at 16:40
2

Do you have any SOQL queries that are using FOR UPDATE? That seems like the best place to start looking for code that would throw an UNABLE_TO_LOCK_ROW exception.

If that is the case could you give some more context about where it is being used?

Improve this answer
1
  • Nope, no FOR UPDATE, but a good thing to check.
    – Benj
    Commented Apr 5, 2013 at 14:29

You must log in to answer this question.

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