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
Miki TosicMiki Tosic 

SFDC Accounts - UNABLE TO LOCK ROW

We use IBM WebSphere Cast Iron to integrate to SFDC. Our Accounts integration executes once per hour, 24x7, and in general processes all data with few issues other than the expected various data issues. However, once per month we run a larger than normal 'upsert' process (i.e. 1000-3000 upserts), and invariably a significant portion of these experience :

UNABLE_TO_LOCK_ROW
unable to obtain exclusive access to this record

Can anyone offer any ideas on what to look for here? We never experience this error with the regular hourly executions (i.e. 50-300 upserts). What could possibly cause the lock issue in this situation? What should be looked for? Is there any way to resolve this issue?

Thanks a lot for any assistance.

Miki Tosic
Life Fitness
Best Answer chosen by Miki Tosic
pconpcon
If you don't mind, please choose the answer as "Best Answer" so that this question is removed from the unanswered queue and so that it can help people in the future.

All Answers

pconpcon
If you are calling these as asyncronous individual upserts you will get this if there is a trigger that is updating a related record and holding the lock.  Ways around this would be to do a bulk upsert of n number of records at one time and repeat those sycronously until you have completed all of your upsert.  Or just do all of them sycronously.
Miki TosicMiki Tosic
Thanks this was helpful.
 
pconpcon
If you don't mind, please choose the answer as "Best Answer" so that this question is removed from the unanswered queue and so that it can help people in the future.
This was selected as the best answer
Nitin jain 37Nitin jain 37
Hi Miki,

Can you please let me know, what you have done in Cast Iron to get rid of this error. We are also facing same issues when upserting opportunities.
Miki TosicMiki Tosic
We could never solve this issue with the original process that encountered the UNABLE_TO_LOCK_ROW error. We do have triggers in place updating relating records, and so we assumed that this must be the issue (per the response from 'pcon'). We can't disable the triggers as we need to have that validation logic in place, and so we were in a "Catch 22" situation unfortunately.

I had to write a new Cast Iron orchestration to follow the original process, and re-process all data failed with UNABLE_TO_LOCK_ROW but this time synchronously and serially (no batch upserts), also per the advice of 'pcon'. This has worked for us.

 
Miki TosicMiki Tosic
In early May of 2015 Salesforce.com systems support moved our production instance from NA6 to NA29, in an effort to provide additional resources and improved performance. Since that time we have not experienced the UNABLE_TO_LOCK_ROW issue once, and we have run our special upsert process (unchanged) a half a doxen times processing thousands of rows of  Accounts data. This would lead me to believe that this is an SFDC performance issue.