I'm trying to write code that will reproduce the Concurrent Requests limit (10 requests longer than 5 seconds, described here:
https://developer.salesforce.com/blogs/engineering/2013/05/force-com-concurrent-request-limits.html). This is so I can judge how likely the error is, and how if will impact our users. So far I have not been able to cause the error to happen.
My attempt was to make a Visual Force page with a button (up to 12 buttons) that would execute a controller method that was guaranteed to run for about 10 seconds of clock time. For the 10 second delay, I used Dan Appleman's concurrency class (see Reproduce UNABLE_TO_LOCK_ROW error and his 2nd edition Advanced Apex book).
But no matter how many times, or how rapidly, I click the VF button(s), the debug logs always show a long series of successful 10+ second logs. I tried one button, 12 buttons,and 1 button across many tabs. In all cases the logs group the controller actions into sets of 6 parallel events, with a large gap between the sets. So, 6 logs are produced with roughly identical start-times, then there is a gap of up about 10 seconds (which matches the delay in the controller), and then another set of 6 logs are generated.
I'm asking for an explanation of why this approach doesn't work. I think that VF is governing how many synchronous requests it will send out, but I can't find documentation on that…? Additionally, I'm asking for a successful approach to generating/demoing the Concurrent Request Limit.
Best Answer
So I managed to create one of these in a package I built, so in case it's helpful here's what I did that caused the error.
I had a synchronous callout to web service. In the response was some data such as remaining credits and the result of the request to the web service. I updated a custom object with the result, but crucially, I also a a record on a custom setting with the data from that response.
A customer added a trigger to my custom object which ran a long running query - but SFDC locks any object being updated by the transaction so it can rollback. So although each record in the custom object was different, every transaction was also trying to update the same record in the custom setting.
Because the trigger was taking a long time to run, every transaction behind it got stuck waiting for the lock on the custom setting to free up, we quickly hit the concurrent transaction error. So I'd suggest trying to create a single choke point that stops the other transactions completing, as that definitely generates that error...