1

I have enabled Disalbe Parallel Apex Testing to solve UNABLE_TO_LOCK_ROW errors. Let test methods run fast, then I add the isParallel annotation to existing test classes. But that can still cause UNABLE_TO_LOCK_ROW errors event thought each test classes create test data isolate.

I checked the errors which mostly the following one:

System.DmlException: Insert failed. 
First exception on row 0; 
first error: UNABLE_TO_LOCK_ROW, 
unable to obtain exclusive access to this record: []

Looking back to my code that causes the error by creating a new lead record.

My question is why does create a new lead record that can still lock the database? Is there another solution except removing the isParallel annotation from the error test class?

2
  • 1
    Part of the problem is the degree of parallel testing when combined with isolation problems between the test cases. Last I checked Salesforce tries to run around 30 tests in parallel and some tests start timing out waiting on locks. It seems to me, other than solving the underling isolation issue, that reducing the number of threads would avoid the issue - Idea Control the degree of parallelism when running apex tests in parallel Commented Jun 16, 2020 at 2:34
  • Thanks for your information. I think my case is seem with you, looking forward Salesforce team to improve that.
    – Jair
    Commented Jun 18, 2020 at 11:22

1 Answer 1

1

This often happens when you have triggers or other related logic that locks a (possibly unrelated) record as part of the record creation process. For example, if you have implemented the "custom auto-number" pattern (e.g. to use conditional auto-numbers), you may use a Custom Setting that will end up being locked repeatedly. While isolated tests (SeeAllData=false) reduces this possibility, all records created during testing can cause locking errors. Note that a deployment to production automatically disables parallel tests; the setting you specify only affects non-deployment test runs. Ideally, your deployment process should not run more tests than necessary; instead of trying to run in parallel, it is often possible to simply run fewer tests.

You must log in to answer this question.

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