alt Hacker NewsNot a user of this particular database, but in event sourcing you dont typically do updates like that? You just add events to the stream.
Is this not a lock per event stream? That would make a lot of sense and make the blocking not an issue as concurrent writes don't work well in that paradigm anyway.
Yes it seems like the locks can be bounded:
> Since such writes are evaluated one after the other, writes that carry such a precondition more often than their query takes make every write wait longer and longer, up to five seconds for each of them ahead of it: keep them rare, or bound the query by event ID or by time where the rule you check allows it.
I guess having a generic precondition could be useful but in general for event sourcing systems the "lock" would usually just be to validate the current state and make sure that no other state was written since the current state was read.