binded / advisory-lock Goto Github PK

In the README, lockShared and unlockShared are documented but aren't exposed on the mutex object returned from the mutex creator factory.

First off - thanks for the great library!

I'm currently troubleshooting an issue with connections not being released after using withLock(). I'll update the issue as I go but if you have any pointers that would be greatly appreciated. Thanks!

Hey there, noticed a small error that means your lock keys are effectively only 5 bytes, instead of the potential 8. The problem is in strToKey, where you do:

return [buf.readInt32LE(0), buf.readInt32LE(1)]

The parameter there is the byte offset, not the sizeof(int32) offset. So what you actually want is:

return [buf.readInt32LE(0), buf.readInt32LE(4)]

To see what I mean, try this:

let buf = Buffer.from([0xff, 0xff, 0, 0, 0, 0, 0, 0])
console.log(buf.readInt32LE(0)) // --> 65535
console.log(buf.readInt32LE(1)) // --> 255

So you're getting bytes 0-3 in your first int, and 1-4 in your second int. What you really want is 0-3 in the first, and 4-7 in the second. In most cases, this probably doesn't make much difference, but it does increase the chances of a collision by quite a lot in theory.

Cheers!

Hi,

I've read the code and noticed the following comment:
// TODO: detect "in process" collisions?

Can you explain if its relevant so I can create PR to fix it? what are these in-process collisions that can occur?

As far as I understand, when creating a hash there is "near-unique" number. If creating lock for the same string multiple times, multiple lock objects will be created, but they all going to function appropriately with their database interactions.

Versions:
node 14.2.0
advisory-lock 1.1.1

Code:

const advisoryLock = require("advisory-lock").default;

const databaseUri = "postgres://db_user:db_password@localhost:5432/postgres"

async function lock() {
  const mutex = advisoryLock(databaseUri)("testLock");
  await mutex.tryLock();
}

lock()
  .then(() => {
    console.log("Success!");
  })
  .catch((e) => {
    console.log("Failure!");
  });

Expected: Either "Success!" or "Failure!" is printed to the console.

What actually happens: Nothing is printed. Node process exits with status code 0 when mutex.tryLock is called.

Why is it an issue: Thisworks as expected in node version prior to 14.0.0.

Hi,

is it possible to set an expiration for the lock? What will happen if the process dies without releasing the lock?

Best regards,
Alex

I'm using this lib to obtain a lock before and after running migrations that run from each of our servers. Unfortunately, it seems like when we run a migration that uses the CONCURRENTLY identified when creating indexes, that migrations hangs.

I'm currently using Sequelize, so I'm assuming there's some sort of deadlock happening. Was wondering if anyone could point me in the right direction. Thank you!

If DSN is not provided at all (e.g. because of the misconfigured environment), advisory-lock silently fails to lock:

> require('advisory-lock').default()('test').tryLock().then(locked => console.log('locked', locked)).catch(console.error)
> locked false

With proper DSN it works:

> require('advisory-lock').default('postgresql://localhost/test')('test').tryLock().then(locked => console.log('locked', locked)).catch(console.error)
> locked true

With wrong DSN it fails (as expected):

> require('advisory-lock').default('postgresql://localhost/no_such_db')('test').tryLock().then(locked => console.log('locked', locked)).catch(console.error)
> { error: database "no_such_db" does not exist ...

Expected behaviour

With undefined DSN, an error is thrown.