Val,
There is no need to have two implementations of the store, the exception
may be handled based on the cache configuration, the store only need to
check whether write-behind is enabled. The configuration change will be
transparently handled by the store. This change can be easily incorporated
t
Alex,
I see your point, but I still think it should be incorporated into the
product.
First of all, your solution implies changing the CacheStore implementation
every time you switch between write-through and write-behind. This
contradicts with the overall design.
Second of all, one of the most
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
Also in addition to that how about generating event when updates are failed
which can be listened to and custom logic can be added to handle the
failures?
On Wed, Aug 29, 2018 at 6:56 AM, Denis Magda wrote:
> Val,
>
> Sounds like a handy configuration option. I would allow setting a number of
>
Val,
Sounds like a handy configuration option. I would allow setting a number of
retries. If the number is set to 0 then a failed update is discarded right
away.
--
Denis
On Tue, Aug 28, 2018 at 9:14 PM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Folks,
>
> Is there a way to l
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 c
