You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Atri Sharma <at...@gmail.com> on 2015/07/02 15:24:13 UTC
IGNITE 514
Andrey,
Since you created JIRA, could you please provide some context around it?
--
Regards,
Atri
*l'apprenant*
Re: IGNITE 514
Posted by Atri Sharma <at...@gmail.com>.
Where is the main putAll method implemented BTW? Or does this change need
to go across all individual implementations of putAll?
On Thu, Jul 2, 2015 at 11:37 PM, 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 <at...@gmail.com>:
>
> > Thanks.
> >
> > Alexey, please advice
> > On 2 Jul 2015 21:43, "Andrey Gura" <ag...@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 <at...@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*
Re: IGNITE 514
Posted by Alexey Goncharuk <al...@gmail.com>.
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 <at...@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 <at...@gmail.com> wrote:
>
> > Sounds good. Let me work on this and get back
> > On 2 Jul 2015 23:37, "Alexey Goncharuk" <al...@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 <at...@gmail.com>:
> >>
> >> > Thanks.
> >> >
> >> > Alexey, please advice
> >> > On 2 Jul 2015 21:43, "Andrey Gura" <ag...@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 <at...@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*
>
Re: IGNITE 514
Posted by Atri Sharma <at...@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 <at...@gmail.com> wrote:
> Sounds good. Let me work on this and get back
> On 2 Jul 2015 23:37, "Alexey Goncharuk" <al...@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 <at...@gmail.com>:
>>
>> > Thanks.
>> >
>> > Alexey, please advice
>> > On 2 Jul 2015 21:43, "Andrey Gura" <ag...@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 <at...@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*
Re: IGNITE 514
Posted by Atri Sharma <at...@gmail.com>.
Sounds good. Let me work on this and get back
On 2 Jul 2015 23:37, "Alexey Goncharuk" <al...@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 <at...@gmail.com>:
>
> > Thanks.
> >
> > Alexey, please advice
> > On 2 Jul 2015 21:43, "Andrey Gura" <ag...@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 <at...@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
> > >
> >
>
Re: IGNITE 514
Posted by Atri Sharma <at...@gmail.com>.
Hi Alexey,
Please advice if this is correct.
On 8 Jul 2015 14:18, "Atri Sharma" <at...@gmail.com> wrote:
> Alexey,
>
> Thanks for your inputs.
>
> I looked through updateAllAsyncInternal0 and see that updateWithBatch is
> only called when there is store configured else entries are updated one by
> one with update Single. So, does that mean that moving the locking inside
> conditional defined by checking for valid store is good enough to ensure
> that 1st requirement of this JIRA is met?
>
> On Thu, Jul 2, 2015 at 11:37 PM, 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 <at...@gmail.com>:
>>
>> > Thanks.
>> >
>> > Alexey, please advice
>> > On 2 Jul 2015 21:43, "Andrey Gura" <ag...@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 <at...@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*
>
Re: IGNITE 514
Posted by Atri Sharma <at...@gmail.com>.
Alexey,
Thanks for your inputs.
I looked through updateAllAsyncInternal0 and see that updateWithBatch is
only called when there is store configured else entries are updated one by
one with update Single. So, does that mean that moving the locking inside
conditional defined by checking for valid store is good enough to ensure
that 1st requirement of this JIRA is met?
On Thu, Jul 2, 2015 at 11:37 PM, 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 <at...@gmail.com>:
>
> > Thanks.
> >
> > Alexey, please advice
> > On 2 Jul 2015 21:43, "Andrey Gura" <ag...@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 <at...@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*
Re: IGNITE 514
Posted by Alexey Goncharuk <al...@gmail.com>.
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 <at...@gmail.com>:
> Thanks.
>
> Alexey, please advice
> On 2 Jul 2015 21:43, "Andrey Gura" <ag...@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 <at...@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
> >
>
Re: IGNITE 514
Posted by Atri Sharma <at...@gmail.com>.
Thanks.
Alexey, please advice
On 2 Jul 2015 21:43, "Andrey Gura" <ag...@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 <at...@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
>
Re: IGNITE 514
Posted by Andrey Gura <ag...@gridgain.com>.
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 <at...@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