<p>General rule of thumb is that if you're serving traffic on more than one craft container, the local mutex system isn't going to work for you, since the containers won't be able to share mutex.</p>
<p>Your point about rolling updates is an interesting one, and will largely depend on how your host implements it. But in a perfect world, a rolling update will spin up your new container, and once it's ready it'll flip all traffic from your old container to it. In that circumstance, a local mutex would likely be fine because there's only one container ever receiving traffic (doesn't apply if you're doing a rolling update that results in multiple containers serving traffic, for the above reason).</p>
<p>There is a small potential window for requests finishing up on the old container and the first few request reaching the new container to simultaneously obtain a mutex for the same operation. Depending on how long these operations are, this'll likely only be a window of a few milliseconds.</p>
<p>To avoid the issue altogether, introduce a shared mutex store (e.g. a redis db) that all containers connect to.</p>

CC BY-SA 4.0
2022-02-26T16:40:16.803Z
2022-02-26T19:04:43.683Z
2022-02-26T19:04:43.683Z
Joe Forshaw
<p>Since the new default in Craft is to use file based mutex (opposed to, the previous default which was?)</p>
<p>Now, since I'm running craft containerized, I can both run it loadbalanced, but it also does a rolling update (meaning that during deployment of changes, it will run multiple containers at the same time).</p>
<p>I haven't really looked into the mutex configuration before, and I'm now wondering what implications this has when upgrading?</p>
<p>Would the scenario of a single container hosting but with rolling updates be at risk of problems with a local mutex system?</p>

<upgrades><mutex>
Are mutex locks used in core Craft?
# Are mutex locks used in core Craft?

(Asked by: username_0 on 2022-02-25)

Since the new default in Craft is to use file based mutex (opposed to, the previous default which was?)

Now, since I'm running craft containerized, I can both run it loadbalanced, but it also does a rolling update (meaning that during deployment of changes, it will run multiple containers at the same time).

I haven't really looked into the mutex configuration before, and I'm now wondering what implications this has when upgrading?

Would the scenario of a single container hosting but with rolling updates be at risk of problems with a local mutex system?

**Tags:** upgrades, mutex

---

## 1 answers

### Answer by username_1 on 2022-02-26. Score: 3

General rule of thumb is that if you're serving traffic on more than one craft container, the local mutex system isn't going to work for you, since the containers won't be able to share mutex.

Your point about rolling updates is an interesting one, and will largely depend on how your host implements it. But in a perfect world, a rolling update will spin up your new container, and once it's ready it'll flip all traffic from your old container to it. In that circumstance, a local mutex would likely be fine because there's only one container ever receiving traffic (doesn't apply if you're doing a rolling update that results in multiple containers serving traffic, for the above reason).

There is a small potential window for requests finishing up on the old container and the first few request reaching the new container to simultaneously obtain a mutex for the same operation. Depending on how long these operations are, this'll likely only be a window of a few milliseconds.

To avoid the issue altogether, introduce a shared mutex store (e.g. a redis db) that all containers connect to.


---

