←back to thread

How to do distributed locking (2016)

(martin.kleppmann.com)
240 points yusufaytas | 3 comments | 20 Oct 24 10:38 UTC | HN request time: 0.715s | 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 #
candiddevmike ◴[20 Oct 24 14:59 UTC] No.41895763[source]▶
One gotcha maybe with locks is they are connection specific AFAIK, and in most libraries you're using a pool typically. So you need to have a specific connection for locks, and ensure you're using that connection when doing periodic lock tests.
replies(2): >>41899383 #>>41901248 #
1. skrause ◴[21 Oct 24 06:34 UTC] No.41901248[source]▶
PostgreSQL has pg_advisory_xact_lock which releases the lock automatically when the transaction is over.
replies(1): >>41902077 #
2. m11a ◴[21 Oct 24 09:02 UTC] No.41902077[source]▶
But then you’d be holding a DB connection for the entire duration of your task (which may include HTTP calls, etc). You might even do asynchronous work in parallel, which doesn’t quite work with txn locks. So the session based locks seem a bit better imo.
replies(1): >>41903621 #
3. eknkc ◴[21 Oct 24 12:51 UTC] No.41903621[source]▶
I personally do these in .NET, I obtain a connection dedicated to that operation, start a transaction, obtain lock and go crazy. Upon completion of the async workflow, the transaction closes and lock releases. I know I'm holding up a connection and putting some pressure on postgres by keeping a transaction open but session management might be harder as the underlying connection provider uses pooling and it is easier to use transactions rather than sessions here.

And if you add something like pgBouncer or whatever, this should still work but a session lock would fuck things up.