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.