[infinispan-dev] Keeping track of locked nodes

[Mircea Markus]

https://issues.jboss.org/browse/ISPN-1857

----- Original Message -----
> From: "Mircea Markus" <mmarkus at redhat.com>
> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
> Sent: Thursday, February 9, 2012 6:04:59 PM
> Subject: Re: [infinispan-dev] Keeping track of locked nodes
> 
> 
> 
> ----- Original Message -----
> > From: "Mircea Markus" <mmarkus at redhat.com>
> > To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
> > Sent: Thursday, February 9, 2012 5:45:08 PM
> > Subject: Re: [infinispan-dev] Keeping track of locked nodes
> > 
> > 
> > 
> > ----- Original Message -----
> > > From: "Dan Berindei" <dan.berindei at gmail.com>
> > > To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
> > > Sent: Thursday, February 9, 2012 4:31:14 PM
> > > Subject: Re: [infinispan-dev] Keeping track of locked nodes
> > > 
> > > On Thu, Feb 9, 2012 at 3:07 PM, Mircea Markus
> > > <mmarkus at redhat.com>
> > > wrote:
> > > >> One potential problem with this design is when we have a
> > > >> transaction
> > > >> prepared on the old primary, and the new primary owner is a
> > > >> cache
> > > >> that
> > > >> just started. The new cache won't have any prepared
> > > >> transactions,
> > > >> so
> > > >> no "backup locks" to prevent new transactions from acquiring
> > > >> the
> > > >> lock.
> > > >> I'm pretty sure this issue has come up in our discussions
> > > >> before,
> > > >> but
> > > >> I can't remember how we decided to handle it.
> > > > I don't rememebr disscussing it but good point.
> > > > The new owner-node being up means that state transfer is
> > > > finished.
> > > > State transfe won't start before the locks on the
> > > > previous-owner
> > > > are released, so there shouldn't be any locking issue. Unless
> > > > I'm
> > > > wrong :)
> > > >
> > > 
> > > State transfer won't start before the prepare command finishes,
> > > but
> > > it
> > > can start in the time between the prepare command and the commit
> > > command.
> > > So it's entirely possible for prepare to run with one CH/primary
> > > owner
> > > and for commit to run with a different CH/primary owner.
> > Ah I see. I thought that the state transfer is blocked until the
> > transaction(v.s. command) completes.
> > if we have numOwners=2, ch(k)={A,B} and C comes up such that
> > ch(k)={C,B} then the second prepare won't be able to acquire lock
> > on
> > B, as there's already a transaction that has prepared in an
> > previous
> > view.
> Thinking some more the old-view approach should happen on C and it
> doesn't, so we're not covered.
> The soutions I see here is to either replay the prepare on C as part
> of the state transfer or not to release the ST lock until the
> transaction (vs the prepare command) is complete.
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>