←back to thread

How to do distributed locking (2016)

(martin.kleppmann.com)
240 points yusufaytas | 2 comments | 20 Oct 24 10:38 UTC | HN request time: 0.402s | source
Show context
eknkc ◴[20 Oct 24 14:27 UTC] No.41895577[source]▶
I tend to use postgresql for distributed locking. As in, even if the job is not db related, I start a transaction and obtain an advisory lock which stays locked until the transaction is released. Either by the app itself or due to a crash or something.

Felt pretty safe about it so far but I just realised I never check if the db connection is still ok. If this is a db related job and I need to touch the db, fine. Some query will fail on the connection and my job will fail anyway. Otherwise I might have already lost the lock and not aware of it.

Without fencing tokens, atomic ops and such, I guess one needs a two stage commit on everything for absolute correctness?

replies(2): >>41895763 #>>41899374 #
1. Quekid5 ◴[20 Oct 24 23:26 UTC] No.41899374[source]▶
Advisory locks have many pitfalls, see [0].

AFAIK the only correct way to do what you probably thought you were doing is "EXCLUSIVE" or "ACCESS EXCLUSIVE"... or two-phase commit or idempotency for the operations you're doing.

[0] https://www.postgresql.org/docs/current/explicit-locking.htm...

replies(1): >>41901268 #
2. skrause ◴[21 Oct 24 06:38 UTC] No.41901268[source]▶
You link to table level locks which are different from advisory locks: https://www.postgresql.org/docs/current/explicit-locking.htm...

Are you sure that you're talking about the same locks? What are the pitfalls exactly?