3

I have a VF page that has been in production for a few weeks; this error was seen for the first time today. I know that locking errors can be sporadic, and the admin couldn't reproduce (logged in as the user). I'm trying to figure out if I need to make any adjustments to my code to prevent this in the future.

The error occurred during a controller method invocation; the method is called as an Action method on a CommandButton. The method runs a query of a custom object, and for each record found, creates a Task and creates a Custom object to be updated; after the loop I insert the list of tasks and update the list of custom objects. The error occurred during the Task Insert.

I've reviewed the code, and tried to eliminate possible causes:

  • The insert is the first place DML is occuring in the method.
  • The SOQL in the method does not use FOR UPDATE.
  • There is one Trigger on Task, but it is an update trigger only, so it is not running.
  • Task is not an M-D child, so no standard Rollups are involved.
  • We use DLRS in the org, but I've confirmed there are no rollups on Task.
  • There are no Workflows or Process Builder processes on Task.

In short, I can't find any "side-effect" DML, so I have to believe that it was the insert itself that caused the error. That doesn't make sense since an Insert should not need to lock records. The tasks I am inserting have both whatid and whoid populated, as well as a custom lookup field to a custom object; does the system lock those related objects for any reason? Any other causes I've overlooked?

  • Maybe the LastActivityDate causes locking issues with the parent. Would be difficult to prove but it's a theory. Any reason you cannot simply add FOR UPDATE to your query? – Adrian Larson Oct 28 '16 at 21:07
  • Assuming it is still the case, the who, what, and account records will lock on task insert if the task status is Completed and the task activity date is not null. link – martin Oct 31 '16 at 1:54
  • 1
    Sounds like you're pretty on-it, but if you haven't seen the locking cheat-sheet, it's well worth a read: resources.docs.salesforce.com/194/0/en-us/sfdc/pdf/… This confirms martin's point that Task can lock Who, What, and Account when "Status is Completed and the ActivityDate is not null". Also note that if your lookup to the custom object is required, that will propagate a lock to the custom object. – Aidan Oct 31 '16 at 8:55
  • @Aidan the link you provided was a lifesaver for me! You should post it as an answer here. Thanks man! – Yonatan Goriachnick Nov 5 '18 at 20:04
1

It's possible that any of the lookups to the whatId, whoId or field to a custom object could create record lock contention issues during your DML operation. If any of those related records were locked as they were being edited, they couldn't be validated during your DML insert of Tasks.

Particularly of concern would the potential that one of them could be deleted during the edit operation. I could see that causing the Unable_to_Lock_Row error you're having. I recommend you set up a "test case" where you're saving an edit on each of those related types of records while also running your trigger to see if you can reproduce the error.

Getting the lock to coincide may take several attempts. Using a large number of records will increase your chances of reproducing the record lock contention

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.