keyless_

4 ms·

1.
by keyless_ 4y ago
Ultimately, you have to trust your clients to do the right thing. The lockable server guarantees that e.g. if multiple /acquire requests come in for the same lock in a short time span, only one request will be successful. You are corre
2.
by keyless_ 4y ago
They are valid solutions for this use-case; the main drawback is you need to set up and maintain a ZooKeeper cluster. Lockable is intended as a simpler and faster-to-use alternative.
3.
by keyless_ 4y ago
It's really up to the client implementation. In order to deal with long-running processes, the client Python implementation uses a separate thread for sending periodic heartbeats to the lockable server, which serves to do 2 things:
4.
by keyless_ 4y ago
Those are valid points. The Python client implementation can be improved, for sure. In particular, the pathological case that is difficult to deal with is the one where the heartbeat thread pauses at the worst possible time (the "patho
5.
by keyless_ 4y ago
Unfortunately, it doesn't. That was actually the reason I built this originally - there's no easy way to control read/write access to a file on S3 without using some sort of external locking system.
6.
by keyless_ 4y ago
Conceptually, that's how it works, however, instead of keeping an HTTP connection open, lockable expects to receive periodic heartbeats /hearbeat to keep the lock acquired. The TTL is variable, and can be set depending on the use
7.
by keyless_ 4y ago
Good questions: > How do you ensure that a lock isn't acquired by two requests? Indeed, the compare and set is done atomically. It's guaranteed that the lock can only be acquired by at most one process. > How do you release
8.
by keyless_ 4y ago
Unfortunately, you do need _some_ sort of TTL because there is no way for the lockable server to know when a remote process has simply died. However, TTLs can be set to be arbitrarily long (e.g. multiple days), which means, in practice, you
9.
by keyless_ 4y ago
Yes, any process can call a heartbeat. If the lock hadn't been acquired (by any process), the heartbeat call fails.
10.
by keyless_ 4y ago
Lockable itself isn't distributed (or, at the very least, doesn't appear distributed from the outside), so I'm not sure if linearizability applies here, but maybe I'm misunderstanding you comment. In a similar vein, I gu
11.
by keyless_ 4y ago
A long held view of mine is that our current architecture where we keep logic on the server and data in the database is rather unfortunate, because it means you either have to * marshall data to your server to process (which can be slow), o
12.
by keyless_ 4y ago
Indeed, the first version of this heavily borrowed from this approach. The trickiest part is correctly writing the logic that spawns the secondary thread used for heartbeats.
13.
by keyless_ 4y ago
Probably ease of setting up and not needing to manage a piece of infrastructure - which is the case with all service offerings, really. It's not a difficult conceptual task to keep track of some locks in a Postgres DB (or use PG adviso
14.
Show HN: Lockable – sync locks for distributed systems(lockable.dev)
77 points by keyless_ 4y ago|49 comments