Editing Shared Resources: "Locking vs Not Locking"

If you’ve been following the “Editing Shared Resources” series you’ll have noticed two choices emerge:

1. Lock the resource and have a slow website

2. Or, don’t lock, but accept some data loss

Locking appears to be a losing game in terms of performance. You can reduce the time spent in a lock, but once you require a lock the core concept still exists. On the other hand, not locking appears to be a losing game in terms of data integrity. Let’s assume that our goal is to keep data integrity, and so we choose to use locks.

We can model the problem with three simple variables:

• waitingTime = Total time the resource will sit and wait before it can acquire a lock.

• lockTime = time spent in a lock

• runningTasks = Number of other tasks that want this lock at the same time.

Assuming locks are granted in an event-loop system like Redis, we can model the time any given request will spend waiting in idle.

waitingTime = runningTasks * lockTime

( Wolfram )

Using this 3d graph you can see that the time in lock increases the overall delay of the entire system (assuming your system’s purpose is to have lots of running tasks). If your website becomes very successful, or you change your frontend to start using a lot of XHR requests, this could seriously reduce overall performance in unexpected ways you rarely see in local development.

So how can we deal with this in a sane way without creating lots of hard-to-maintain code?