Editing Shared Resources: "Yolo Locks"

I’m sure there’s a proper name for this but I like this term. Sometimes code is designed to just start executing. It assumes it has the right to change some data simply because it is running, so it (for example) changes some value in a database. This is the default behaviour of any application that doesn’t have code for resource locking. It will work 100% of the time, but only if you limit it to 1 process (and no threads) that can ever access that value. Two is too many. Three is right out.

The moment a second process is introduced, it runs code with the instructions “just overwrite whatever was there, I don’t care what it was”. This can be fine in some very specific business cases, but generally speaking, it isn’t very useful and usually breaks things.

Imagine a situation where two Web Servers are writing Session Data to Redis for the same Session Cookie.

( Interactive diagram link )
Note: I’m using solid lines to identify SETs, dotted lines to identify GETs, I know that official UML uses them differently. I just think it looks cleaner on this specific diagram.

Once you serve more than 1 web request at the same time for the same user, this turns into a bug. So this is not a good general solution, but will work for very specific cases that never need to scale beyond 1 worker.

This post is part of a series on editing shared resources. More posts are coming soon.