Best way to prevent race conditions in a multi instance web environment?

Question

Say you have an Action in ASP.NET MVC in a multi-instance environment that looks something like this*:

public void AddLolCat(int userId)
{
    var user = _Db.Users.ById(userId);

    user.LolCats.Add( new LolCat() );

    user.LolCatCount = user.LolCats.Count();

    _Db.SaveChanges();
}

When a user repeatedly presses a button or refreshes, race conditions will occur, making it possible that LolCatCount is not similar to the amount of LolCats.

Question

What is the common way to fix these issues? You could fix it client side in JavaScript, but that might not always be possible. I.e. when something happens on a page refresh, or because someone is screwing around in Fiddler.

• I guess you have to make some kind of a network based lock?
• Do you really have to suffer the extra latency per call?
• Can you tell an Action that it is only allowed to be executed once per User?
• Is there any common pattern already in place that you can use? Like a Filter or attribute?
• Do you return early, or do you really lock the process?
• When you return early, is there an 'established' response / response code I should return?
• When you use a lock, how do you prevent thread starvation with (semi) long running processes?

* just a stupid example shown for brevity. Real world examples are a lot more complicated.

Answer 1

Answer 1: (The general approach)
If the data store supports transactions you could do the following:

using(var trans = new TransactionScope(.., ..Serializable..)) {
    var user = _Db.Users.ById(userId);
    user.LolCats.Add( new LolCat() );
    user.LolCatCount = user.LolCats.Count();
    _Db.SaveChanges();
    trans.Complete();
}

this will lock the user record in the database making other requests wait until the transaction has been committed.

Answer 2: (Only possible with single process)
Enabling sessions and using session will cause implicit locking between requests from the same user (session).

Session["TRIGGER_LOCKING"] = true;

Answer 3: (Example specific)
Deduce the number of LolCats from the collection instead of keeping track of it in a separate field and thus avoid inconsistency issues.

Answers to your specific questsions:

• I guess you have to make some kind of a network based lock?
  yes, database locks are common

• Do you really have to suffer the extra latency per call?
  say what?

• Can you tell an Action that it is only allowed to be executed once per User
  You could implement an attribute that uses the implicit session locking or some custom variant of it but that won't work between processes.

• Is there any common pattern already in place that you can use? Like a Filter or attribute?
  Common practice is to use locks in the database to solve the multi instance issue. No filter or attribute that I know of.

• Do you return early, or do you really lock the process?
  Depends on your use case. Commonly you wait ("lock the process"). However if your database store supports the async/await pattern you would do something like

  var user = await _Db.Users.ByIdAsync(userId);
  

  this will free the thread to do other work while waiting for the lock.

• When you return early, is there an 'established' response / response code I should return?
  I don't think so, pick something that fits your use case.

• When you use a lock, how do you prevent thread starvation with (semi) long running processes?
  I guess you should consider using queues.

Answer 2

By "multi-instance" you're obviously referring to a web farm or maybe a web garden situation where just using a mutex or monitor isn't going to be sufficient to serialize requests.

So... do you you have just one database on the back end? Why not just use a database transaction?

It sounds like you probably don't want to force serialized access to this one section of code for all user id's, right? You want to serialize requests per user id?

It seems to me that the right thinking about this is to serialize access to the source data, which is the LolCats records in the database.

I do like the idea of disabling the button or link in the browser for the duration of a request, to prevent the user from hammering away on the button over and over again before previous requests finish processing and return. That seems like an easy enough step with a lot of benefit.

But I doubt that is enough to guarantee the serialized access you want to enforce.

You could also implement shared session state and implement some kind of a lock on a session-based object, but it would probably need to be a collection (of user id's) in order to enforce the serializable-per-user paradigm.

I'd vote for using a database transaction.

Answer 3

I suggest, and personally use mutex on this case.

I have write here : Mutex release issues in ASP.NET C# code , a class that handle mutex but you can make your own.

So base on the class from this answer your code will be look like:

public void AddLolCat(int userId)
{
    // I add here some text in front of the number, because I see its an integer
    //  so its better to make it a little more complex to avoid conflicts
    var gl = new MyNamedLock("SiteName." + userId.ToString());
    try
    {
        //Enter lock
        if (gl.enterLockWithTimeout())
        {
            var user = _Db.Users.ById(userId);    
            user.LolCats.Add( new LolCat() );    
            user.LolCatCount = user.LolCats.Count();    
            _Db.SaveChanges();
        }
        else
        {
            // log the error
            throw new Exception("Failed to enter lock");
        }
    }
    finally
    {
        //Leave lock
        gl.leaveLock();
    }
}

Here the lock is base on the user, so different users will not block each other.

About Session Lock

If you use the asp.net session on your call then you may win a free lock "ticket" from the session. The session is lock each call until the page is return.

Read about that on this q/a:
Web app blocked while processing another web app on sharing same session
Does ASP.NET Web Forms prevent a double click submission?
jQuery Ajax calls to web service seem to be synchronous

Answer 4

Well MVC is stateless meaning that you'll have to handle with yourself manually. From a purist perspective I would recommend preventing the multiple presses by using a client-side lock, although my preference is to disable the button and apply an appropriate CSSClass to demonstrate its disabled state. I guess my reasoning is we cannot fully determine the consumer of the action so while you provide the example of Fiddler, there is no way to truly determine whether multiple clicks are applicable or not.

However, if you wanted to pursue a server-side locking mechanism, this article provides an example storing the requester's information in the server-side cache and returns an appropriate response depending on the timeout / actions you would want to implement.

HTH

Answer 5

One possible solution is to avoid the redundancy which can lead to inconsistent data. i.e. If LolCatCount can be determined at runtime, then determine it at runtime instead of persisting this redundant information.