function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
glorgeglorge 

Upsert Error: "unable to obtain exclusive access to this record"

I'm seeing this error relatively frequently as I attempt to upsert data to Salesforce. However, it isn't 100% repeatable - if I try to run the same batch job again it is a different set of records that fails to upsert.

Some notes on our upload process:

1. We are using multi-threading to increase upload speed.
2. We are *not* upserting the same record at the same time with multiple threads. (A given record only appears once in the batch upload process).
3. The object we are upserting to does have an Apex trigger on it - but this trigger only modifies the record being updated, so we should not run into any locking issues here.
4. The object we are upserting is included in a roll-up summary.

I'm thinking that maybe it's the parent in the roll-up summary that is being locked? Does this sound plausible?

I'll be investigating further. Just wondering if anyone else has ever run into this error...

-Greg

Message Edited by glorge on 11-12-2008 05:10 PM
SuperfellSuperfell
Yes, the parent will be locked. We generally advise against trying to multithread update/upsert calls because of the implications of lock management.
glorgeglorge
Thanks for the quick response. I was indeed able to verify that turning off multi-threading fixed the problem (to that extent that one can ever be sure that a locking issue has gone away).

Interestingly, I have not been able to reproduce the issue in our Sandbox. Therefore, I wasn't able to confirm that it was specifically the combination of multi-threading and roll-up summaries that was causing the problem. Since things had been running fairly stable (with multi-threading) until I changed a couple of lookup relationships into master-detail relationships, though, I'm inclined to think that must be the problem.

Overall, given the amount of the trouble I've gotten myself into with multi-threaded upserts, I plan to follow your advice in the future and look for other ways to save time.

Thanks again,
Greg
glorgeglorge
Oops - back again. After dropping down to a single thread of execution, I've found that I'm still getting the occasional locking issue which causes an entire block of upserts to fail.

After reading through the API for a bit I found this...

"Deadlocks involve at least two transactions that are attempting to update overlapping sets of objects. Note that if the transaction involves a summary field, the parent objects are locked, making these transactions especially prone to deadlocks. To debug, check your code for deadlocks and correct. Deadlocks are usually not the result of an issue with Salesforce operations."

If I'm upserting a block of 200 records, any number of which may share the same parent (and factor into the same roll-up summary, which in turn drives a formula field), is it reasonable to assume that Salesforce is smart enough to order its operations such that no deadlocks will occur?

Message Edited by glorge on 11-18-2008 06:39 PM
SuperfellSuperfell
Correct, a single API call can't deadlock itself.
glorgeglorge
Maybe it's a user? If a user had the parent record open in "edit" mode, would that lock the record? How about in "read" mode?
trublutrublu

glorge,

 

Could you please let me know what you found out please?

 

We are experiencing the same issue...

 

Thanks a lot!

glorgeglorge

In our case I can confirm that it was a combination of multi-threaded upserting and roll-up summaries. (In my third post, where I said I had turned off multi-threading, it turns out there was a bug on our side that was allowing multiple threads to access the API).  

 

For example, say you have three records - A, B, and C - where B and C are "details" and A is the "master". Furthermore, assume that B and C "roll up" into A via a roll-up summary.  What I've found is that:

 

  • Trying to update B and C via two concurrent API calls will lead to a concurrency error
  • Updating B and C within a single API call will *not* lead to a concurrency error

I hope this information is helpful.

-Greg
Message Edited by glorge on 04-22-2009 03:17 PM
Ken_KoellnerKen_Koellner

I've found this thread very useful but didn't see an answer to the edit mode question.

 

Anyone know if having the record open in "edit" mode will lock the record or is it only when the update is actually executed, i.e., when they hit save?

 

SuperfellSuperfell
the record is only locked during the save operation.
MycodexMycodex

Apologies for reviving a dead thread but just in case someone searches this, I found I reduced the amount of record locking errors if I sorted the 'detail' records by the master unique key. I also offloaded transformations from a trigger to a ETL program. I used Talend Open Source (www.talend.com) and it works pretty well as a code generation ETL program. I'm not sure this could be used for roll-up summaries on the master. I also use the Apex Data Loader CLI for batch processing serial upserts over night. Hope this helps...

Lindsay RoseLindsay Rose

Thanks to everyone who has contributed to this thread. I have to say this may be one of the most informative/useful posts I have seen on the force discussion boards. This information has not helped resolve my issue, but after reading the thread I actually have an idea about what is causing this error in my org.

 

Thank You!!!

Jeremy DJeremy D

Hi There 

I encountered the same issue "unable to obtain exclusive access to this record"  when I tried to load a set of data into SF.
and got the same issues hours later.

When I ignored that set of data and load a new set, the issue  was gone..

For some reason one or more record in that set was locked.  How can I find out what and why that record(s) is locked?

 

Sammy Lamba 3Sammy Lamba 3
A lot of the suggestions in this thread are a little over my head, but I was able to glean enough information to come up with a workaround for my data load. I just reduced the batch size from 200 to 10. This avoided overlapping issues, and in @JeremyD's case, it would help isolate the locked record. The dataload take a lot longer, but it was better than nothing.
Phil WPhil W
We got this error in a different context; we were inserting instances of an object in concurrent executions where the objects being inserted have a lookup field to a related object where that lookup has "<deleteConstraint>Restrict</deleteConstraint>" (i.e. the related object cannot be deleted while there is an object referencing it). The way Salesforce works in this case is that it locks (or attempts to lock) the related object. If it can't lock it then the insert fails.

Our workaround was to change the relationship to allow the reference to be nulled, but then set up a trigger that disallows deletion of the related object when there are still objects referencing it.
Renee HughesRenee Hughes
I have just had the same error, I deactivated the dupe rules and all records went in without any failures. 
EDGAR SANTOS ATENCOEDGAR SANTOS ATENCO
Hello Renee! Excuse me, where its this dupe rules I'm adminsitrator and I've the same problem.