multi-key (not composite keys)

[ORESoftware]

https://chatgpt.com/share/e/69eafa82-6f24-8010-b6f0-43b9061e449d

take a look at live-mutex https://github.com/oresoftware/live-mutex how could we improve the code to lock not on composite keys but on two keys if we have user1 and writeFavoritesForUser1 we maye want to lock on user1 and writeFavoritesForUser1 - we could do this: lockKey = ${user1}:${writeFavoritesForUser1} but locks the intersection not the union we could do this: await getLock(${user1}); await geLock(${writeFavoritesForUser1}); but that's slower and more http reqs - instead we want: getMultiLock([user1, writeFavoritesForUser1]); and the lock/mutex broker handles it is this possible?

---

Yes — getMultiLock([user1, writeFavoritesForUser1]) is possible, and it’s the right abstraction.

Composite key:

"user1:writeFavoritesForUser1"

locks only that exact intersection. It won’t conflict with a lock on user1 alone.

The safer design is broker-side atomic multi-key acquisition:

const lock = await client.acquireMany(['user1', 'writeFavoritesForUser1']);

try {
  // critical section
} finally {
  await lock.release();
}

Implementation idea:

1. Add client command type, e.g. type: 'lock-many', with keys: string[].
2. Broker canonicalizes keys: dedupe + sort.
3. Broker grants only if all keys are currently available.
4. If any key is held, enqueue the request as one waiter object attached to all relevant keys.
5. On unlock of any key, broker reevaluates queued multi-lock requests.
6. Unlock releases all keys using one lockUuid.

Sorting is important even though acquisition is broker-atomic; it gives deterministic fairness and avoids deadlock if fallback logic ever acquires per-key. Live-Mutex already has the right architecture for this because the broker is the single source of truth for locks, and the current broker stores lock state by key with wait queues/lockholders. ([GitHub]1)

I would not implement it as:

await getLock(user1);
await getLock(writeFavoritesForUser1);

unless the client library wraps it with deterministic ordering + rollback, because two clients can deadlock:

A locks user1, waits for writeFavoritesForUser1
B locks writeFavoritesForUser1, waits for user1

Recommended API shape:

await client.acquireMany(keys, opts);
await client.releaseMany(keys, { id });

or better:

const unlock = await client.acquireMany(keys);
await unlock();

Return value:

{
  acquired: true,
  keys: ['user1', 'writeFavoritesForUser1'],
  id,
  unlock,
  release: unlock
}

So: yes, possible, and it should be done in the broker, not by inventing composite keys and not by sequential client-side locks.

[ORESoftware]

Yes. I’d implement it additively, not by rewriting the existing single-lock path.

Repo shape: the current hot spots are src/client.ts and src/broker-1.ts; broker messages already route by data.type, with lock, unlock, ls, etc., and lock state lives in locks = new Map<string, LockObj>().

Minimal design:

client.acquireMany(keys, opts)
client.releaseMany(keys, opts)

Wire protocol:

{ type: 'lock-many', keys, uuid, ttl, keepLocksAfterDeath }
{ type: 'unlock-many', keys, uuid, lockUuid }

Broker-side, add only two new methods:

private normalizeKeys(keys: string[]) {
  return [...new Set(keys)].sort();
}

private canAcquireMany(keys: string[]) {
  return keys.every(k => {
    const lck = this.locks.get(k);
    return !lck || lck.lockholders.size < lck.max;
  });
}

Then:

lockMany(data, ws) {
  const keys = this.normalizeKeys(data.keys);
  const lockUuid = data._uuid || data.uuid;

  if (!this.canAcquireMany(keys)) {
    this.multiNotify.push({ ...data, keys, ws });
    return;
  }

  for (const key of keys) {
    const lck = this.locks.get(key) || this.getDefaultLockObject(key, data.keepLocksAfterDeath, data.max);
    this.locks.set(key, lck);

    lck.lockholders.set(lockUuid, {
      pid: data.pid,
      ws,
      uuid: lockUuid
    });

    this.wsToKeys.get(ws)[key] = true;
  }

  this.send(ws, {
    type: 'lock-many',
    acquired: true,
    keys,
    uuid: data.uuid,
    lockUuid,
    id: lockUuid
  });
}

On unlock:

unlockMany(data, ws) {
  const keys = this.normalizeKeys(data.keys);
  const lockUuid = data.id || data.lockUuid || data._uuid || data.uuid;

  for (const key of keys) {
    const lck = this.locks.get(key);
    if (!lck) continue;

    lck.lockholders.delete(lockUuid);

    if (lck.lockholders.size < 1 && lck.notify.length < 1) {
      this.locks.delete(key);
    }
  }

  this.send(ws, {
    type: 'unlock-many',
    unlocked: true,
    keys,
    uuid: data.uuid,
    id: lockUuid
  });

  this.drainMultiNotify();
}

And the key piece:

drainMultiNotify() {
  for (const req of [...this.multiNotify]) {
    if (!this.canAcquireMany(req.keys)) continue;

    this.multiNotify.remove(req.uuid);
    this.lockMany(req, req.ws);
  }
}

I would not try to reuse the existing per-key notify queue for multi-locks. That’s where LOC and bugs explode. Add a separate broker-level multiNotify queue, and call drainMultiNotify() after every normal unlock() and unlockMany().

Client side is small: copy the existing acquire() / release() pattern, but validate keys: string[], dedupe/sort, store one resolution callback by uuid, and send type: 'lock-many'.

The important rule: multi-locks are all-or-nothing. Never partially acquire user1 and then wait for writeFavoritesForUser1.

So, yes: probably ~100–180 LOC total if you keep it separate from existing single-lock logic.