Lock API does not allow locking from one process and unlocking from another process about etcd3 HOT 6 CLOSED

Thanks for the issue, I'll add capability for this tonight :)

from etcd3.

Thanks for your fast reply.

Also, wanted to clarify something with you.
If I take lock on mylock2 key using etcdctl and then try to take lock using this library on the same key, both of them goes through.

As far as I understood from the source code, the lock API underlying is using lease. Hence I guess it is not the blocking etcd lock that you offer, rather a non blocking lock implementation using the lease feature. Is that understanding correct ?

from etcd3.

The locks this library provides should be compatible with those in the etcdctl as this is in large part based upon the official etcd Go client which the ctl consumes, however I have not verified this myself, so there might be a subtle difference or two. I'll give it a look. PRs also welcome of course.

from etcd3.

Just to explain it in more detail,

I have written a code like this.

const {
    Etcd3
} = require('etcd3');
const client = new Etcd3({
    hosts: "10.244.14.255:4001"
});

const lock = client.lock("mylock2");
lock.ttl(5).acquire()
    .then(lock => {
        console.log("Lock taken", lock);
    })

When I run the code, it acquires the lock.

Now at the same time, if I run the command etcdctl --endpoints=10.244.14.255:4001 --insecure-skip-tls-verify=true lock mylock2 then that acquires the lock as well,

$ etcdctl --endpoints=10.244.14.255:4001 --insecure-skip-tls-verify=true lock mylock2
mylock2/16ce63390ae29664

Is this really expected?

from etcd3.

Heyo, sorry for the delay here. The etcdct Go client client implements locks a little differently. Specifically, their lock implementation blocks on Lock() and attempts to guarantee fairness as to who gets the lock when it releases. Whereas in this implementation, we simply throw if we cannot acquire the lock.

It may be good to get closed to the etcd implementation as theirs is more robust and closer to a 'true' mutex. But, as a result, they use slightly different keys which don't conflict with the ones that this client provides.

from etcd3.

In 56ea496 I've added a new method to the lock, leaseId(), which returns the owner lessor of the lock. Using this, in your second process, you can run this to release the lock:

client
  .if(myLockKey, 'lease', '==', leaseId)
  .then(client.delete(myLockKey))

from etcd3.