Thanks for that.
I totally appreciate the fact that this is not a quick ticket and that it
involves understanding of locking synchronizations (both are the reasons
why I picked this ticket). I also poked about function calls a lot hence
have specific questions around the code.
Specifically:
My understanding now says that the main call that actually handles putAll
operation is IgniteTxLocalAdapter.putAllAsync0 (coming down from
GridCacheAdapter). Is that correct?
In IgniteTxLocalAdapter.putAllAsync(), if I understand correctly,
txLockAsync() is the call that actually locks the entries, so logic around
this method needs to be modified for ATOMIC cache case,right?
On Fri, Jul 3, 2015 at 8:25 PM, Dmitriy Setrakyan <
[hidden email]>
wrote:
> On Fri, Jul 3, 2015 at 5:39 AM, Atri Sharma <
[hidden email]> wrote:
>
> > Folks,
> >
> > Can someone please explain a bit around GridCacheAdapter#putAll's logic
> > please? I am trying to understand which part works with locking.
> >
>
> Atri, I think the best way to understand how this logic works is to set a
> breakpoint there and trace it all the way through. This way you will get an
> idea of which pieces are involved.
>
> Having said that, IGNITE-514 is a very delicate ticket and requires deep
> understanding of how locking and synchronization work for atomic operations
> in Ignite. If you want to tackle this ticket, you will need to spend enough
> time tracing through the execution path and making sure you understand all
> the intricate details. This is not a quick ticket.
>
>
> > Regards,
> >
> > Atri
> >
> > --
> > Regards,
> >
> > Atri
> > *l'apprenant*
> >
>
--
Regards,
Atri
*l'apprenant*
Locked
