Perhaps you want to think of this as a “divide and conquer” approach. It’s simple in theory: the session data is not just one big resource, instead, it is many really small resources which don’t need to all get changed at the same time. Imagine you had a Flash Message, Authenticated User ID, and a Navigation History List. Each would get their own specific resource.

It sounds good because:

Almost no code needs to change the Auth’d user: only login, and logout code will change that.
Breadcrumbs are quick to compute, so the total window for holding this lock is small.
Flash messages are rare events, so most of the time there’s no need to lock anything.
(flash messages are those little notifications that show up one time after a redirect from a form submission).

One can imagine how much this improves the overall performance by reducing the need to keep extra time in a lock.

However, there’s a few problems if you go with this. First of all, if your application was designed in a way that there actually is a relationship between the two partitions (in our case, breadcrumbs and flash messages) you won’t be able to use this solution because you need to lock both every time. The second, more challenging issue is something called deadlock, which will make your two workers “wait” in their pessimistic locks forever.

Imagine some psudo-code controllers like this:

Worker1 Controller
    Acquire breadcrumb lock
    Acquire Flash message lock
    Add to breadcrumb
    Add to flashmessage some value from breadcrumb
    release flashmessage lock
    release breadcrumb lock

Worker2 Controller
    Acquire Flash message lock
    Acquire breadcrumb lock
    Add to breadcrumb
    release flashmessage lock
    release breadcrumb lock

This kind of problem could be reduced with better architecture and some clever code. Perhaps rules about nesting locks would help too. However, the problem is that a developers must be fully aware of this issue everywhere it is used. It can probably work on a small team with no turnover and less than 100 files to maintain. If you cross that million-lines-of-code threshold, or grow to a team of 50 developers, or you just lose the one “locking code guru on our team” who understood the issue and put in enough effort to review this correctly… this bug will show up in your system. Eventually.

Eventually might be good enough for your system, and it might be abstracted away so that most of the problem is avoided. Nevertheless, running software changes frequently and this design opened the door to this problem. Eventually this will happen, and it’s so difficult to see where the issue is introduced it is unlikely to be caught in a simple code review.

Articles and Posts

Editing Shared Resources: "Many Individual locks"