ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Kulichenko <valentin.kuliche...@gmail.com>
Subject Re: Ignite 2.0 tasks/roadmap
Date Thu, 11 Aug 2016 23:06:18 GMT
There is one more use case where several types per cache can be useful (I
know that it's utilized by some of our users). The use case is the
following: transactional updates with write-behind and foreign key
constraints on the database. In case data within transaction is collocated
and all types are in the same cache, it works, because there is only one
write-behind queue. Once we split different types into different caches,
there is no guarantee that objects will be written in the proper order and
that the constraints will not be violated.

However, I think this is not a very clean way to achieve the result.
Probably we should just provide better support for this use case in 2.0.
Basically, we somehow need to allow to share a single write-behind queue
between different caches.

Any thoughts?

-Val

On Thu, Aug 11, 2016 at 10:40 AM, Dmitriy Setrakyan <dsetrakyan@apache.org>
wrote:

> On Thu, Aug 11, 2016 at 7:25 AM, Sergey Kozlov <skozlov@gridgain.com>
> wrote:
>
> > Alexey
> >
> > You're right. Of course I meant growth of caches number.
> >
> > I see a few points here:
> >
> > 1. If a grid used by various applications the cache names may overlap
> (like
> > "accounts") and the application needs to use prefixed names and etc.
> > 2. For clear or destory caches I need to know their names (or iterate
> over
> > caches but I'm not sure that it is supported by API). For destroy/clear
> > caches belonging to same group we will do it by single operation without
> > knowledge of cache names.
> > 3. Cache group can have cache attributes which will be inherited by a
> cache
> > created in that group (like eviction policy or cache mode).
> > 4. No reason to add specific feature like SqlShema if it applicable for
> > regular caches as well.
> >
>
> Sergey K, setting the same SQL schema for multiple caches, as proposed by
> Sergi, solves a different problem of having too many SQL schemas due to too
> many different caches. I think Sergi proposed a good solution for it.
>
>
> >
> > On Thu, Aug 11, 2016 at 6:58 PM, Alexey Kuznetsov <
> akuznetsov@gridgain.com
> > >
> > wrote:
> >
> > > Sergey, I belive you mean "increase" instead of "reduce"?
> > >
> > > How grouping will help?
> > > To do some operation, for example, clear on group of cashes at once?
> > >
> > > 11 Авг 2016 г. 22:06 пользователь "Sergey Kozlov" <
> skozlov@gridgain.com>
> > > написал:
> > >
> > > > I mean not only SQL features for caches. Single type per cache
> > definitely
> > > > reduces number of caches for regular user and grouping caches will
> help
> > > to
> > > > manage caches in grid.
> > > >
> > > > On Thu, Aug 11, 2016 at 5:41 PM, Sergi Vladykin <
> > > sergi.vladykin@gmail.com>
> > > > wrote:
> > > >
> > > > > I'm aware of this issue. My plan was to allow setting the same
> schema
> > > > name
> > > > > to different caches using CacheConfiguration.setSqlSchema(...).
> This
> > > way
> > > > > we
> > > > > will have separate caches but from SQL point of view respective
> > tables
> > > > will
> > > > > reside in the same schema. No need to introduce new concepts.
> > > > >
> > > > > Sergi
> > > > >
> > > > >
> > > > > 2016-08-11 17:24 GMT+03:00 Sergey Kozlov <skozlov@gridgain.com>:
> > > > >
> > > > > > HI
> > > > > >
> > > > > > Due to approach to disable to store more than one type per cache
> > the
> > > > > cache
> > > > > > use becomes similar the table use for databases.
> > > > > > So I suppose would be good to introduce a database/schema-similar
> > > > concept
> > > > > > for caches. It may be implemented as a non-default behavior
for
> > > > backward
> > > > > > compatibility.
> > > > > >
> > > > > > On Sat, Aug 6, 2016 at 1:04 AM, Dmitriy Setrakyan <
> > > > dsetrakyan@apache.org
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > On Fri, Aug 5, 2016 at 2:46 AM, Alexey Kuznetsov <
> > > > > > akuznetsov@gridgain.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I remember couple more thing for 2.0
> > > > > > > >
> > > > > > > > How about to drop **ignite-scalar** module in Ignite
2.0?
> > > > > > > >
> > > > > > >
> > > > > > > Why?
> > > > > > >
> > > > > > >
> > > > > > > > And may be drop **ignite-spark-2.10** module support
as of
> > > > **Spark**
> > > > > 2
> > > > > > is
> > > > > > > > on **scala 2.11**.
> > > > > > > >
> > > > > > >
> > > > > > > I would drop it only if it is difficult to support. Do
we know
> > what
> > > > > kind
> > > > > > of
> > > > > > > impact will it have on the community? Anyone is still using
> 2.10?
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Aug 2, 2016 at 11:09 PM, Denis Magda <
> > > dmagda@gridgain.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Let’s add this [1] issue to the list because
it requires
> > > > > significant
> > > > > > > work
> > > > > > > > > on the side of metrics SPI.
> > > > > > > > >
> > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-3495
<
> > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-3495>
> > > > > > > > >
> > > > > > > > > —
> > > > > > > > > Denis
> > > > > > > > >
> > > > > > > > > > On Aug 2, 2016, at 12:45 AM, Yakov Zhdanov
<
> > > > yzhdanov@apache.org>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Not yet. The thing is that our recent experience
showed
> > that
> > > it
> > > > > was
> > > > > > > not
> > > > > > > > > > very good idea to go with caches. E.g. when
you try to
> > > > > deserialize
> > > > > > > > inside
> > > > > > > > > > continuous query listener on client side
it implicitly
> > calls
> > > > > > > > cache.get()
> > > > > > > > > > which in turn may cause deadlock under some
> circumstances.
> > > > > > > > > >
> > > > > > > > > > --Yakov
> > > > > > > > > >
> > > > > > > > > > 2016-08-02 2:41 GMT+03:00 Dmitriy Setrakyan
<
> > > > > dsetrakyan@apache.org
> > > > > > >:
> > > > > > > > > >
> > > > > > > > > >> On Mon, Aug 1, 2016 at 3:46 AM, Yakov
Zhdanov <
> > > > > > yzhdanov@apache.org>
> > > > > > > > > wrote:
> > > > > > > > > >>
> > > > > > > > > >>> One more point.
> > > > > > > > > >>>
> > > > > > > > > >>> I insist on stop using marshaller
and meta caches but
> > > switch
> > > > to
> > > > > > > > > spreading
> > > > > > > > > >>> this info via custom discovery events.
> > > > > > > > > >>>
> > > > > > > > > >>
> > > > > > > > > >> Do we have a ticket explaining why this
needs to be
> done?
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>>
> > > > > > > > > >>> --Yakov
> > > > > > > > > >>>
> > > > > > > > > >>> 2016-07-27 19:57 GMT+03:00 Dmitriy
Setrakyan <
> > > > > > > dsetrakyan@apache.org
> > > > > > > > >:
> > > > > > > > > >>>
> > > > > > > > > >>>> On Wed, Jul 27, 2016 at 11:36
AM, Yakov Zhdanov <
> > > > > > > > yzhdanov@apache.org>
> > > > > > > > > >>>> wrote:
> > > > > > > > > >>>>
> > > > > > > > > >>>>> Guys, I think we can also
split event notification
> for
> > > user
> > > > > > > > listeners
> > > > > > > > > >>> and
> > > > > > > > > >>>>> internal system listeners.
I have been seeing a lot
> of
> > > > issues
> > > > > > > > caused
> > > > > > > > > >> by
> > > > > > > > > >>>>> some heavy or blocking operations
in user-defined
> > > > listeners.
> > > > > > This
> > > > > > > > may
> > > > > > > > > >>>> block
> > > > > > > > > >>>>> internal component notification
(e.g. on discovery
> > event)
> > > > > > causing
> > > > > > > > > >>>> topology
> > > > > > > > > >>>>> hangings.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>> Sure. There are a lot of features
being added. Would
> be
> > > nice
> > > > > to
> > > > > > > > assign
> > > > > > > > > >> a
> > > > > > > > > >>>> release manager for Ignite 2.0
and document all the
> > > > discussed
> > > > > > > > features
> > > > > > > > > >> on
> > > > > > > > > >>>> the Wiki.
> > > > > > > > > >>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> --Yakov
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> 2016-06-25 2:42 GMT+03:00
Alexey Goncharuk <
> > > > > > > > > >> alexey.goncharuk@gmail.com
> > > > > > > > > >>>> :
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>> Folks,
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> Recently I have seen
a couple of emails suggesting
> > > > > > > > > >> tasks/improvements
> > > > > > > > > >>>>> that
> > > > > > > > > >>>>>> we cannot do in 1.x
releases due to API
> compatibility
> > > > > reasons,
> > > > > > > so
> > > > > > > > > >>> they
> > > > > > > > > >>>>> are
> > > > > > > > > >>>>>> postponed to 2.0. I
would like to keep track of
> these
> > > > tasks
> > > > > in
> > > > > > > > some
> > > > > > > > > >>> way
> > > > > > > > > >>>>> in
> > > > > > > > > >>>>>> our Jira to make sure
we do not have anything
> obsolete
> > > > when
> > > > > it
> > > > > > > > > >> comes
> > > > > > > > > >>> to
> > > > > > > > > >>>>> the
> > > > > > > > > >>>>>> next major version release.
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> My question for now
is how should we track such
> tasks?
> > > > > Should
> > > > > > it
> > > > > > > > > >> be a
> > > > > > > > > >>>>>> label, a parent task
with subtasks, something else?
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> I would go with a label
+ release version.
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> --AG
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Alexey Kuznetsov
> > > > > > > > GridGain Systems
> > > > > > > > www.gridgain.com
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Sergey Kozlov
> > > > > > GridGain Systems
> > > > > > www.gridgain.com
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Sergey Kozlov
> > > > GridGain Systems
> > > > www.gridgain.com
> > > >
> > >
> >
> >
> >
> > --
> > Sergey Kozlov
> > GridGain Systems
> > www.gridgain.com
> >
>

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