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