ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Setrakyan <dsetrak...@apache.org>
Subject Re: New method in IgniteCache API.
Date Wed, 20 Jan 2016 03:09:30 GMT
I still believe the difference is very subtle for a naked eye. Seems like
both, topology validator and data loss check are almost identical:

- both get invoked whenever topology changes
- both can prohibit some operation on cache, e.g. updates in case of
topology validator or updates/reads/both in case of data loss check

I think the design screams for these two abstractions to be combined into
one. Otherwise, we are only going to muddle the API.

D.

On Fri, Jan 15, 2016 at 12:17 AM, Alexey Goncharuk <
alexey.goncharuk@gmail.com> wrote:

> Still not sure how they are similar:
>
> TopologyValidator is invoked on every topology change and provides a
> boolean result whether topology is ready to be used. Currently there is no
> way to mark a 'failed' topology as valid without another topology change.
>
> This new method that Vladimir suggests resets the partition state after it
> has been lost, it does not invoke topology validator and does not need a
> topology change to work.
>
> 2016-01-15 10:59 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:
>
> > Alexey,
> >
> > All I am saying is that the difference between topology validator and
> this
> > new method becomes very subtle. One just looks like a subset of another.
> Am
> > I wrong?
> >
> > D.
> >
> > On Thu, Jan 14, 2016 at 2:38 AM, Alexey Goncharuk <
> > alexey.goncharuk@gmail.com> wrote:
> >
> > > Dmitriy,
> > >
> > > Are you suggesting that we need to pass partitions state to a topology
> > > validator so that user needs to check it manually. I do not think this
> is
> > > convenient for an end-user and like the approach with the policy that
> > > Vladimir suggested better.
> > >
> > > Raul,
> > >
> > > I assume you want to add IgniteCacheEx interface? How one would get it?
> > > Another thing that crossed my mind was that it may be more efficient to
> > > reset the state of multiple caches simultaneously, so maybe we should
> add
> > > this method to Ignite and pass a list of cache names?
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message