Maybe you have found the problem with multiple users concurrently editing and updating the same record. I came across this when I implemented a “get next lead” function for a company a while ago. I created a simple VF page comprising a single button that will find the next lead to work on (using an ordered SOQL query in the controller) bringing up the detailed edit page of that lead.
The problem arises when more than one user presses that button at the same time. What will happen is that the two users will execute the same query that in fact will select and bring up the detailed edit page for the same lead record. After editing the last user pressing save will get an error message since the first user already started editing the record. This is actually a problem on all objects in Salesforce whenever two or more users edit the same record. So I needed a way of preventing the users to start editing the same record.
Having a background as writing low level (close to hardware) software for embedded systems I was thinking of semaphores having the ability to give the user exclusive access to a resource. Does that exist in Salesforce? No, but let’s invent one. I needed to get something that is really fast and provides an exclusive lock. The solution was a custom setting (for speed) since it is fully cached in memory and a unique value field.
When the first user creates a new record of a custom setting object with a field value set to the lead id it will be successful. But when the second user tries to create another record using the same lead id an exception will be thrown due to no duplicates are allowed. By catching the exception you can write a method that will return true for successful claim of the lead and false if the lead was already claimed.
I let the query return 10 lead ids, wrap those lead ids in a loop that calls the newly invented method that tries to claim one lead id at a time until it succeeds. When the claim succeeds a field on the corresponding lead record must be updated with some value to make it disappear from the next soql query result, thus hiding it from other users pressing the “get next lead”-button.
Finally the editing user returns the lead by restoring the lead field value. To solve the release of the semaphore I added code in the semaphore claim method that release all semaphores older than 10 seconds. This could be done since the claim of the lead that sets the field on the lead to make it disappear will take max 3 seconds giving me a buffer of 7 seconds just to be sure.
Another front/end implementation could be a VF-page (with no visible components) and a controller that overrides the standard edit button for the lead. If claim succeeds it will bring up the detailed edit page for that record but if the claim fails it will show an error on the VF-page that the record is busy.
Please make a comment if you want me to give you an example in source code.
Senior Salesforce and Force.com Developer and Consultant
Originally published in Peter's own blog 15.1.2015
Photo Taylor Davis