feat: add leader election API into coordination client about ydb-go-sdk HOT 5 CLOSED

как тебе вариант сначала создавать локер (без серверного вызова), а потом блокировки дёргать уже через него?
контекст при возврате тогда точно не нужен, ошибка тут опциональна - тольпо для проверки аргумента ресурса.

locker := db.Coordination().CreateLocker("resource")
ctx, err := locker.Lock(ctx)
...
locker.Unlock(ctx)


ctx, err := locker.Lock(ctx, WithLockCount(3))
...
locker.Unlock(ctx, WithLockCount(2)) // тут как я понял надо дать возможность частичной разблокировки.
// если разблокировать можно только тот вес, что взял - при анлоке эту опцию просто не допускать.

from ydb-go-sdk.

// wait for lock
// Returned ctx with cancel, 
// use it for operations under lock
locker, ctx, err := db.Coordination().Lock(
  ctx, 
  "resource", 
  coordination.WithCount(2),
)
If err != nil {
  // wrap err
}
defer locker.Unlock(
  coordination.WitchCount(2),
)
// Doing under lock

from ydb-go-sdk.

Here one use case from the wild. We need to launch migrations in global (in scope of database) lock to eliminate concurrent database modification: golang-migrate/migrate#677 (comment)

from ydb-go-sdk.

Наверное так можно будет разделить блокировки. Есть ещё нюанс - ресурс надо создавать с одинаковым счётчиком на всех клиентах. Если первый клиент ждёт локер на 10, а второй на 100, то надо возвратить где-то ошибку

from ydb-go-sdk.

Если счётчик всегда одинаковый - зачем он вообще нужен? тогда получается это просто shared-lock с ограничением на количество локов и параметр не нужен.

from ydb-go-sdk.