Integration with Web Locks

[inexorabletash]

Web Locks provide a generic origin-scoped mutex. This is useful for things like implementing transactions across multiple storage endpoints, ensuring only one window/worker is syncing data across the network, etc.

I believe we should support web locks within buckets, in addition to the storage APIs. Use cases:

• Origins that want to partition storage by "app" e.g. having a "chat" bucket and a "mail" bucket for ease of development and maintenance. While namespacing can be done manually just like Caches/Indexed DB (e.g. prefix your cache/database/lock with "mail::" or "chat::"), buckets are a great primitive for this.

• In a future where we expose buckets across contexts (e.g. allowing passing a bucket cross-origin via postMessage(), or in a sharded storage case allowing a third party frame access to first party buckets) then appropriately locks should similarly be available.

We'll need to invent semantics e.g. if a bucket is deleted, should the locks be dropped?

[pwnall]

Thank you! This is a great point.

I agree that we should add Web Locks to the list of integration points for Buckets.

[ayuishii]

Added to the explainer, thanks!

[evanstade]

thanks for reopening. We still need to decide how to deal with bucket deletion.

We'll need to invent semantics e.g. if a bucket is deleted, should the locks be dropped?

Currently, if we do nothing, then deleting a bucket has no effect on locks. There's currently no concept of dropping a lock (unlike, say, idb being force closed) so that also has to be invented. Every other API that Buckets exposes is part of the quota management system, whereas locks are not, which makes it kind of the odd one out, and perhaps confusing from an API perspective? (It does nothing, for example, to ensure that operations inside the lock callback are only performed on that bucket's storage endpoints.)

As noted, it's possible to manually roll namespaces. And if that's done, the locks will all be visible in navigator.locks.query. So making this part of the buckets API also implies the subtle difference of hiding the locks from navigator.locks.query, unless we decide it shouldn't do that and we go out of our way to make them all appear in the default lock manager.

Due to these edge cases not having a clear answer and potentially requiring non-trivial amounts of work, I might question whether the first bullet point (no need to manually add a namespace) is sufficient justification. The second bullet point I don't fully grasp. Can/should we not expose locks across contexts on their own, to handle locks from navigator.locks?