Comment by paulgb
1 year ago
Great write-up!
> If we extend it further with a fairly simple distributed mutex mechanism, we can now persist and share state across any service which can access the Redis instance!
I’m curious to hear more about the approach you took here. Does the first server to open the document hold the mutex, or do servers only hold the mutex when briefly while they persist data?
(I’ll also shamelessly plug Y-Sweet, an open source Yjs server with persistence that I contribute to https://github.com/jamsocket/y-sweet)
Blog author here!
> or do servers only hold the mutex when briefly while they persist data?
This: it's only held during document updates, which in itself is an operation we debounce to avoid unnecessarily hammering the DB. Eventual consistency is our friend here, so this isn't a high frequency requirement (as I'm sure you're aware!).
If you can nail the "sync-on-close" mechanism in browsers, then you're golden :-)
How do you handle it within y-sweet (cool project, BTW!)?
Makes sense, thanks!
We run Y-Sweet in Plane.dev (also our open source project). Plane runs a process for every document across a pool of compute, so each process effectively has a lock on that document’s data and can persist on a loop without worrying about conflicting with another writer.