ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Goncharuk <alexey.goncha...@gmail.com>
Subject Re: IGNITE 514
Date Tue, 07 Jul 2015 00:58:23 GMT
Atri,

The places you are referring in the code are related to TRANSACTIONAL
cache. From the top of my head the key classes that require changes are
GridNearAtomicUpdateFuture, GridDhtAtomicUpdateFuture and
GridDhtAtomicCache. Specifically, the logic related to the entries locking
is located in the method updateAllAsyncInternal0. These classes//methods
mostly handle all operations in ATOMIC cache. The logic related to the keys
sorting - which is absent now - I think should be placed in the near update
future.

2015-07-03 2:49 GMT-07:00 Atri Sharma <atri.jiit@gmail.com>:

> Alexey,
>
> I have been researching around ticket and am trying to understand which
> parts to change.
> If I understood correctly, is GridCacheAdapter#putAll where change is
> needed in this case?
>
> On Thu, Jul 2, 2015 at 11:47 PM, Atri Sharma <atri.jiit@gmail.com> wrote:
>
> > Sounds good. Let me work on this and get back
> > On 2 Jul 2015 23:37, "Alexey Goncharuk" <alexey.goncharuk@gmail.com>
> > wrote:
> >
> >> Here is the idea behind this ticket:
> >>
> >> Currently when putAll is invoked on an ATOMIC cache, all involved
> entries
> >> are locked on primary nodes. The entries are locked as a batch on
> primary
> >> nodes in order to support batch update of a cache store. To avoid
> >> deadlocks, we require a user to provide a proper ordering of the keys
> >> being
> >> passed to putAll methods. This requirement can be relaxed:
> >>  - We do not need to lock all entries as a batch if there is no store
> >> configured or skipStore flag is set. Individual entry updates should be
> >> enough.
> >>  - When cache store is configured, we can change the order of entries in
> >> putAll because this is not a transactional cache. Currently we can
> exploit
> >> the fact that the keys are already represented as CacheObjects and use
> >> their serialized form to provide unified ordering and avoid deadlocks.
> >>
> >> 2015-07-02 9:17 GMT-07:00 Atri Sharma <atri.jiit@gmail.com>:
> >>
> >> > Thanks.
> >> >
> >> > Alexey, please advice
> >> > On 2 Jul 2015 21:43, "Andrey Gura" <agura@gridgain.com> wrote:
> >> >
> >> > > Atri,
> >> > >
> >> > > Unfortunatelly I can't give any advice. May be Alexey Goncharuk can
> >> help.
> >> > >
> >> > >
> >> > >
> >> > > On Thu, Jul 2, 2015 at 4:24 PM, Atri Sharma <atri.jiit@gmail.com>
> >> wrote:
> >> > >
> >> > > > Andrey,
> >> > > >
> >> > > > Since you created JIRA, could you please provide some context
> around
> >> > it?
> >> > > >
> >> > > > --
> >> > > > Regards,
> >> > > >
> >> > > > Atri
> >> > > > *l'apprenant*
> >> > > >
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Andrey Gura
> >> > > GridGain Systems, Inc.
> >> > > www.gridgain.com
> >> > >
> >> >
> >>
> >
>
>
> --
> Regards,
>
> Atri
> *l'apprenant*
>

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