Is it a correct case of usage Redlock

I’ve just read about the redlock algorithm and can’t figure out is it a correct case of usage. Let’s say I have a few workers and an observable which spies on some database. I use timeout to randomly pick a worker:

const redlock = new Redlock([...], { retryCount: 0 });

...

sub.on('message', (channel, message) => setTimeout(async () => {
  try {
    var lock = await redlock.lock('db1' /* use parsed message in the real app */, 1000);
  } catch (e) {
    console.log(e);
  }

  if (lock) {
    const watcher = new DatabaseObservable('db1').subscribe(
      message => {
        console.log(m); // something has changed in the database
      },

      err => {
        lock.unlock(); // the connection to the database was interrupted
      },

      () => {
        lock.unlock(); // the connection to the database was closed normally 
      }
    );

    try {
      while (1) {
        await sleep(800); // hmm... the lock here could become dead
        lock = await lock.extend(1000);
      }
    } catch (e) { ... }
  }
}, Math.random()));

sub.subscribe('watch')

When I need to create a new database observable I do redis.publish('watch', 'db1'). For each database there can be only one observable at the same time. The lock unlocks once the connection to the database is interrupted or closed.

1. Does Redlock fit my case?
2. What is the right way here to extend locks?
3. Connections to the databases could be interrupted. So I want to recover them. Can I set an interval which repeats Redis.publish('watch', 'db1') unless the key is locked? Something like:

// in the server process around a websocket connection

setInterval(() => {
  if ( /* unlocked */) {
    redis.publish('watch', 'db1')
  }
}, 1000);

[mike-marcacci]

2 - Setting the TTL is case-dependent. The main effects you need to consider are:

a) deadlock recovery time: the longer the TTL, the longer the resource stays locked if your app crashes before releasing the lock, or if a network issue makes unlocking impossible b) exclusivity window: the sorter the TTL, the greater the risk that a network issue makes extending impossible, in which case you should stop your task if possible

Generally:

• if the resource you are locking is infrequently contested (like the ID of a task), you probably want to use longer TTL (say, a minute) and not worry about extending
• if your task keeps track of progress or can be safely paused/resumed, use a small TTL and extend frequently
• never cut an extension closer than say ~50ms, as a brief burst of open files, a large garbage collection event, or a network event might add enough latency to miss your window

Your current settings seem completely sane without knowing too much about what you’re doing.

3 - This is correct, and something I do frequently for a user-supplied task; however, I’d suggest also reading through #14, as I wouldn’t do anything destructive assuming that a lock is held by another process (vs. we simply can’t get a lock right now). I think I should probably add something about this to the readme.

Just out of curiosity, are working on coordination for therondb? It’s a really cool looking project!

[mike-marcacci]

Great to hear, and no problem! I’m going to be following Theron, it’s a really cool project.