News for hackers. Stuff that matters.
Re:Distributed Locks with Redis by hinkley on Wednesday August 21, 2024 @10:09PM (#41316088)
If it goes dark a microsecond after #3 you might have an ambiguous success. Transaction processed but you didn't get a confirmation.

A lot of robust systems end up implementing their own bespoke WAL semantics on top of the system of record. It's like we should have a formal solution for doing that by now.

Re:Distributed Locks with Redis by alexey-salmin on Wednesday August 21, 2024 @11:58PM (#41316682)
True. Even simple scenarios like "save a file in s3 IFF the s3 link is saved in postgres" which are seen in virtually any application are rarely handled well.
Re:Distributed Locks with Redis by physicles on Thursday August 22, 2024 @12:35AM (#41316863)
Uggh, I was cornered into writing a couple of these over the years. The way I handled it was:

1. make sure both operations will be retried if they don't run to completion, and

2. think through how the rest of the system would react to one of them being present without the other

Then I use whichever of the two orderings is less bad from the perspective of #2. Obviously this depends on the exact use case -- I was simply lucky that the rest of the system was designed in such a way that it could tolerate that bad intermediate state.

Re:Distributed Locks with Redis by qaq on Thursday August 22, 2024 @01:35AM (#41317149)
We do we have globally distributed ACID DBs like Spanner, CockroachDB, FoundationDB etc.