Open tso opened 1 year ago
Any update on this merge please? we are using this library and are stuck with this issue of instances not able to acquire locks when DDB has stale locks, Please reply so that we can wait for the new version or choose a different approach.
Thanks in Advance
Bumping the above question, we'd also love to see this merged!
FYI, there is an alternative fix that doesn't require using a wall clock time.
This commit addresses issue #44 by providing a new option to utilize wall clock time along with a provided error bound to determine if a lock is expired.
Previously it was impossible to determine if a lease was expired without blocking for at least lease duration and seeing if the version had changed. Thus, if you never block and the lease wasn't explicitly marked as released then the lock was unable to ever be acquired again. By providing a correct upper clock skew error bound clients can correctly take over locks which have expired but not been explicitly released without blocking.
In most distributed systems relying on wall clock time is generally not correct but in this case we can provide an upper clock skew error bound on the scale of minutes without facing any negative consequences for most clients. This tradeoff of having a lease be unacquireable for several minutes is possibly better than being forced to block in many use cases.