-
Notifications
You must be signed in to change notification settings - Fork 172
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More granular error codes #43
Comments
Hi @fider! This is a perfectly reasonable request, but I think we’ll have to refine your suggested API a bit. Since redlock is highly available it can receive errors (or failures) on a minority of attempts and still acquire the lock. It’s possible that we reach a quorum and return the acquired lock before all attempts have finished, and the subsequent ones could potentially fail. The other case is that a majority of attempts fail, which can happen from a combination of failures (lock is already acquired) and errors. Again, we can be certain of failure before we actually receive all the responses. Perhaps both the |
Another complication is that of retries... |
Hi Mike, I got your point - `await lock()` request (promise) should not be
rejected in each case because it will destory flow. Emitting event also
have no sense in "classic" application that use step-by-step (non event)
flow.
IMO. it makes sense to reject it in case if connection to each db will
fail, are you ok with this (or this is already implemented behavior)?
pon., 1 paź 2018 o 07:38 Mike Marcacci <[email protected]>
napisał(a):
… Another complication is that of retries...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#43 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABY-TmNnFYUh-EpKzeei_IxONkBL1ej6ks5ugapugaJpZM4W2YmU>
.
--
*Wojciech Fiderek*
Mobile: +48 516 661 428
|
I am doing something wrong or there is a fundumental problem with Redlock api. It's somewhat hard to properly use it for optimistic locking. I assume that among many parallel requests one should acquire a lock and others should just give up right away because I only want some computation to be done exactly once. Redlock throws an exception whenever it fails to acquire a log. But I actually indend to sometimes fail acquiring the lock. This is not an error to handle. As such maybe it should not have been implemented through an exception. Exceptions are for errors, not for normal flow of algorithm. |
Hi @germansokolov13 - are you actually experiencing a thrown exception? In normal usage the API either rejects a |
@mike-marcacci In JavaScript when you use async/await syntax rejecting a promise translates into |
The newest version has all the relevant information attached to an error. Accessing all of this information is still a bit complex, because we can sometime know that something has errored before all parallel requests have completed. See the tests for an example of how to inspect these: node-redlock/src/single.test.ts Lines 14 to 31 in 078c727
|
Hello.
Briefly - how would I detect situation where I cannot get lock because of all Redis instanes gone (eg. db connection error on all instances).
More details:
Is there a way I can distinguish between type of errors, eg:
Is it possible that you will introduce LockError.code property and expose (export) some LOCK_ERROR_CODE_... consts?
Regards,
Wojtek
The text was updated successfully, but these errors were encountered: