Replies: 5 comments
-
Hi, @cwarden! First of all thanks for your interest in our library. We would really like to have such functionality like fair locking. As I understood IfOldestLease flag would instruct backend to enable some additional non-blocking mode which could be used on the client side to implement more fair locking. If someone already waits for the lock we cannot await together, so first locker will have a priority over us. That's sounds ok, I would like to have such mode for an OptimisticLockingStorageBasedBackend. Some ideas how IfOldestLease may be called another way: BlockIfOldestLease, NonBlockIfLeasesReserved, BlockIfNoLeases. By the way, it may also be possible to implement FairLock mode on backend side, this option could be supported only by some in-memory backend. |
Beta Was this translation helpful? Give feedback.
-
The way I've been thinking about it is that the clients would be waiting together. Clients may stop waiting so they need to keep checking in to tell the server, "I'm still waiting". If a client stops sending these "I'm still waiting" messages, it's no longer eligible to get the lease; the server assumes it no longer wants it. Only the client that started waiting first and has sent an "I'm still waiting" message recently (one that hasn't timed out yet) is eligible to take the lease when it's available. |
Beta Was this translation helpful? Give feedback.
-
Ok, now I see. Even if some client was first and is now awaiting, it is not a reason to deny another client which tries to get lease, because there is a chance that first client will suddenly disconnect and another client will actually receive the lease. |
Beta Was this translation helpful? Give feedback.
-
Anyway, I would like to review and fully understand your implementation, feel free to bring a PR. |
Beta Was this translation helpful? Give feedback.
-
The approach I came up with is to add an optional AcquirerId to the AcquireOptions. This is used to hold the acquirer's place in line. The queue is stored on the lock for which the acquirer is waiting. This avoids having to deal with the challenges of updating multiple locks, the shared lock for the queue and the exclusive lock wanted, like my original idea. See #42 |
Beta Was this translation helpful? Give feedback.
-
When the lock is unavailable and there are multiple callers waiting to acquire it, I'd like to give it to the one waiting the longest.
I'm thinking about having each caller acquire a shared lock first and renew it while waiting to acquire the non-shared lock. I can a property to
AcquireOptions
likeIfOldestLease LockHandle
. WhenOptimisticLockingStorageBasedBackend.Acquire
is called, ifIfOldestLease
is set, check to see if there are any other active shared leases for the same lock. If so, return an error.Does this sound like a reasonable approach? Any other suggestions?
Beta Was this translation helpful? Give feedback.
All reactions