Question

I have an asp.net MVC4 application that I am using Unity as my IoC. The constructor for my controller takes in a Repository and that repository takes in a UnitOfWork (DBContext). Everything seems to work fine until multiple ajax requests from the same session happen too fast. I get the Store update, insert, or delete statement affected an unexpected number of rows (0) error due to a concurrency issue. This is what the method looks like called from the ajax request:

public void CaptureData(string apiKey, Guid sessionKey, FormElement formElement)
{
        var trackingData = _trackingService.FindById(sessionKey);
        if(trackingData != null)
        {
             formItem = trackingData.FormElements
                          .Where(f => f.Name == formElement.Name)
                          .FirstOrDefault();

             if(formItem != null)
             {
                formItem.Value = formElement.Value;
                _formElementRepository.Update(formItem);
             }
        }
}

This only happens when the ajax requests happens rapidly, meaning fast. When the requests happen at a normal speed everything seems fine. It is like the app needs time to catch up. Not sure how I need to handle the concurrency check in my repository so I don’t miss an update. Also, I have tried setting the “MultipleActiveResultSets” to true and that didn’t help.

Answer 1

As you mentioned in the comment you are using a row version column. The point of this column is to prevent concurrent overwrites of the same row. You have two operations:

• Read record – reads record and current row version
• Update record – update record with specified key and row version. The row version is updated automatically

Now if those operations are executed by concurrent request you may receive this:

• Request A: Read record
• Request B: Read record
• Request A: Write record – changes row version!
• Request B: Write record – fires exception because record with row version retrieved during Read record doesn’t exist

The exception is fired to tell you that you are trying to update obsolete data because there is already a new version of the updated record. Normally you need to refresh data (by reloading current record from the database) and try to save them again. In highly concurrent scenario this handling may repeat many times because simply your database is designed to prevent this. Your options are:

• Remove row version and let requests overwrite the value as they wish. If you really need concurrent request processing and you are happy to have “some” value, this may be the way to go.
• Not allow concurrent requests. If you need to process all updates you most probably also need their real order. In such case your application should not allow concurrent requests.
• Use SQL / stored procedure instead. By using table hints you will be able to lock record during Read operation and no other request will be able to read that record before the first one save changes and commits or rollbacks transaction.