When should I use LockManager.request() to serialize work across tabs instead of in-memory locks?

A local mutex works only as long as every contender runs in the same JavaScript heap. That is a narrower world than many web apps actually live in. Once the same origin can run in two tabs, a tab and a worker, or two workers, each context has its own memory and its own copy of any flag, promise, or singleton you create. A module-level boolean can stop reentry inside one context, but it cannot stop another context from starting the same job because the other context never sees that boolean at all.

That is the first reason to reach for the Web Locks API instead of an in-memory lock. The browser, not your application object graph, becomes the coordinator across contexts. MDN describes Web Locks as a way for scripts running in one tab or worker to asynchronously acquire a lock, hold it while work is performed, and release it automatically afterward. The resource is named by your app, but the arbitration happens at the browser level for the origin.

This distinction matters when the unsafe work is side-effecting and short enough to be modeled as a critical section. Syncing a cache, refreshing an index, writing a migration marker, or updating shared state are all examples where two overlapping starts can create duplicated writes or bad ordering. In those cases, a local lock is at best a partial defense. It can reduce races inside one context, but it cannot serialize the same origin as a whole.

`navigator.locks.request()` is the entry point you use when you want the browser to decide who owns a named lock. You pass a lock name, optional options, and a callback. When the lock is granted, the browser invokes the callback with a `Lock` object. When the callback returns, or the returned promise settles, the lock is released. That shape makes the protected region explicit: the work inside the callback is the work that must not overlap.

The browser also queues later requests for the same name. That queueing is the practical difference from a boolean flag or a custom promise chain. If one context already holds the lock, another same-name request waits its turn instead of guessing whether the resource is free. MDN also documents `mode: "exclusive"` and `mode: "shared"`. Exclusive mode means only one holder at a time. Shared mode means multiple readers can coexist, while an exclusive writer must wait until the shared holders leave.

That readers-writer split is useful when the operation is not purely write-only. A reader that only inspects a shared cache may be safe to overlap with other readers, while a writer that mutates the same cache needs to wait. The important point is that `request()` is not just a callback wrapper. It is a browser-level ownership protocol with queueing semantics that your own in-memory lock cannot provide across tabs or workers.

There are three practical limits to keep in mind before you design around Web Locks. First, the API is available only in secure contexts. That means you should expect it on HTTPS pages, not on arbitrary insecure origins. Second, MDN documents support in Web Workers, and the interface is exposed through `WorkerNavigator.locks` as well as `navigator.locks`. So the coordination primitive is not limited to the main window thread.

Third, the scope is origin, not page. Two same-origin tabs participate in the same lock namespace. Two different origins do not. This is exactly why the API is useful for cross-tab serialization without a custom broker or a broadcast-channel protocol. A lock name is just an application-chosen string; the browser enforces it within the origin’s lock manager.

That origin boundary also explains when you should not overuse the API. If the resource is private to one component instance or one tab, the browser is probably unnecessary overhead. If the resource crosses tabs or workers, a local mutex is too small. Web Locks fills the middle ground where you need coordination, but you do not want to build your own arbitration service just to protect a short critical section.

The two modes cover the most common concurrency choices. Use `exclusive` when only one code path should hold the resource at a time: one writer, one indexer, one migration, one reconciliation job. Use `shared` when you want multiple readers at once, but still need to block writers until those readers finish. The browser enforces that relationship for you. You do not have to approximate it with a manually managed counter or a homegrown lock queue.

Even so, the lock does not replace your application logic. It does not make a non-idempotent operation safe by itself, and it does not roll back durable side effects if your code has already written them. The lock only prevents overlap while the callback is active. If the callback updates several records or writes a progress marker, your data model still needs to account for retries, partial completion, and replay.

That is the useful mental model: the lock protects ownership, not every state transition in the system. Put only the unsafe branch inside the callback. Any expensive preparation that can happen before the decision to modify shared state should stay outside the lock. That keeps the queue short and makes it easier to reason about what was actually serialized.

In practice, this means the lock boundary should match the real contested resource, not the entire feature. If the resource is a shared index, protect the index update. If it is a cache rebuild, protect the rebuild. If it is a write step in a larger workflow, protect the write step and let the surrounding orchestration remain outside the critical section.

A common reaction to cross-tab races is to add a flag in storage, or to debounce the trigger in each tab, and then call the problem solved. Those partial fixes can reduce frequency, but they do not change ownership. Two contexts can still observe the same state before either one updates it. Two debounced triggers can still overlap after the delay window. The result is timing improvement, not serialization.

A storage-backed flag is also awkward because it mixes durable state with live coordination. If you use the same persistence layer for both, you now need a compare-and-swap style protocol just to decide which context may begin. That protocol can work, but it is more complex than asking the browser for a lock. The Web Locks API exists precisely to provide the live coordination primitive directly.

The better rule is simple: use a local mutex when the race lives entirely inside one JavaScript context. Use `navigator.locks.request()` when the same origin can execute the same operation in more than one context. Put the contested branch inside the callback, let the browser queue the rest, and keep durability concerns in the storage layer that actually owns the data.

This separation is why the API is especially useful for background work. A worker can coordinate with a tab, a tab can coordinate with another tab, and neither one has to know which context started first. The browser owns the queue. Your code owns the data model and the recovery path.

The supplied implementation uses an injected in-memory lock manager so the example can be tested deterministically. That shim is useful because it models the public shape of `request()`: exclusive and shared modes, `ifAvailable`, `steal`, queueing, and automatic release after the callback finishes. The tests then exercise the helper functions that call into that shim. One test verifies that two exclusive requests serialize. Another verifies that `ifAvailable` returns `null` when the lock is already held. A third verifies that shared holders can overlap and that an exclusive waiter runs only after the shared holders release.

That evidence is real, but its scope is narrow. The tests prove the behavior of the injected shim and the helper functions that use it. They do not prove that a specific browser build behaves the same way under every edge case, because a Node test runner is not a browser conformance suite. The browser-level guarantees come from the MDN-documented API contract, while the tests show how to structure a critical section and how to observe queueing deterministically in the sample code.

The tests are still valuable because they force the article’s central claim to stay concrete. An exclusive request cannot enter before the first exclusive holder finishes. A shared request can overlap with another shared request. An immediate probe can fail fast when a lock is busy. Those are the behaviors a reader needs to recognize before deciding whether their own application should use `navigator.locks.request()`.

The important negative case is also visible: this fixture does not pretend to simulate tab crashes, browser process restarts, or full production coordination across a real origin. It demonstrates the lock boundary and queue behavior. The reader still has to use the actual browser API in their application and design storage recovery separately if a job can leave durable partial work behind.