Since the write-behind store wraps the store provided by a user, I think the correct solution would be to catch the exception and not propagate it further in the store, because only the end-user knows which errors can be retried, and which errors cannot.
In this case no changes in the write-behind logic is needed. ср, 29 авг. 2018 г. в 7:14, Valentin Kulichenko < [email protected]>: > Folks, > > Is there a way to limit or disable retries of failed updates in the > write-behind store? I can't find one, it looks like if an update fails, it > is moved to the end of the queue and then eventually retried. If it fails > again, process is repeated. > > Such behavior *might* be OK if failures are caused by database being > temporarily unavailable. But what if update fails deterministically, for > example due to a constraint violation? There is absolutely no reason to > retry it, and at the same time it can cause stability and performance > issues when buffer is full with such "broken" updates. > > Does it makes sense to add an option that would allow to limit number of > retries (or even disable them)? > > -Val >
