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 a lock reliably? How do you solve the problem of releasing accidentally while using a resource?
A lock is released in one of two conditions:
1. the /release endpoint is called
2. the lease on the lock expires
I'm not sure what you mean by "releasing accidentally" - if nobody calls /release then the lock won't be released.
> Can the lock jam locked if the process dies?
Locks come with a lease which expires after a set amount of time. If lockable doesn't receive a heartbeat to renew the lease, the lock is released automatically.
> I would use Consul for this or I would try avoid needing to lock to begin with.
For sure Consul is an alternative, so are ZooKeeper and things like ETCD - lockable is intended to be a no-setup alternative to something like that.
> 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 a lock reliably? How do you solve the problem of releasing accidentally while using a resource?
A lock is released in one of two conditions:
I'm not sure what you mean by "releasing accidentally" - if nobody calls /release then the lock won't be released.> Can the lock jam locked if the process dies?
Locks come with a lease which expires after a set amount of time. If lockable doesn't receive a heartbeat to renew the lease, the lock is released automatically.
> I would use Consul for this or I would try avoid needing to lock to begin with.
For sure Consul is an alternative, so are ZooKeeper and things like ETCD - lockable is intended to be a no-setup alternative to something like that.