Apache Ignite Developers - Legacy Mail Archive

IGNITE 514

Classic

List

Threaded

10 messages Options

Atri Sharma

IGNITE 514

Andrey,

Since you created JIRA, could you please provide some context around it?

--
Regards,

Atri
*l'apprenant*

Andrey Gura

Re: IGNITE 514

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 <[hidden email]> 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

Atri Sharma

Re: IGNITE 514

Thanks.

Alexey, please advice
On 2 Jul 2015 21:43, "Andrey Gura" <[hidden email]> 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 <[hidden email]> 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
>

Alexey Goncharuk

Re: IGNITE 514

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 <[hidden email]>:

> Thanks.
>
> Alexey, please advice
> On 2 Jul 2015 21:43, "Andrey Gura" <[hidden email]> 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 <[hidden email]> 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
> >
>

Atri Sharma

Re: IGNITE 514

Sounds good. Let me work on this and get back
On 2 Jul 2015 23:37, "Alexey Goncharuk" <[hidden email]> 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 <[hidden email]>:
>
> > Thanks.
> >
> > Alexey, please advice
> > On 2 Jul 2015 21:43, "Andrey Gura" <[hidden email]> 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 <[hidden email]>
> 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
> > >
> >
>

Atri Sharma

Re: IGNITE 514

In reply to this post by Alexey Goncharuk

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 <
[hidden email]> wrote:

--
Regards,

Atri
*l'apprenant*

Atri Sharma

Re: IGNITE 514

In reply to this post by Atri Sharma

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 <[hidden email]> wrote:

> Sounds good. Let me work on this and get back
> On 2 Jul 2015 23:37, "Alexey Goncharuk" <[hidden email]>
> 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 <[hidden email]>:
>>
>> > Thanks.
>> >
>> > Alexey, please advice
>> > On 2 Jul 2015 21:43, "Andrey Gura" <[hidden email]> 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 <[hidden email]>
>> 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*

Alexey Goncharuk

Re: IGNITE 514

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 <[hidden email]>:

> 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 <[hidden email]> wrote:
>
> > Sounds good. Let me work on this and get back
> > On 2 Jul 2015 23:37, "Alexey Goncharuk" <[hidden email]>
> > 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 <[hidden email]>:
> >>
> >> > Thanks.
> >> >
> >> > Alexey, please advice
> >> > On 2 Jul 2015 21:43, "Andrey Gura" <[hidden email]> 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 <[hidden email]>
> >> 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*
>

Atri Sharma

Re: IGNITE 514

In reply to this post by Alexey Goncharuk

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 <
[hidden email]> wrote:

--
Regards,

Atri
*l'apprenant*

Atri Sharma

Re: IGNITE 514

Hi Alexey,

Please advice if this is correct.
On 8 Jul 2015 14:18, "Atri Sharma" <[hidden email]> 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 <
> [hidden email]> 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 <[hidden email]>:
>>
>> > Thanks.
>> >
>> > Alexey, please advice
>> > On 2 Jul 2015 21:43, "Andrey Gura" <[hidden email]> 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 <[hidden email]>
>> 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*
>