Re: [infinispan-dev] Keeping track of locked nodes

https://issues.jboss.org/browse/ISPN-1857 ----- Original Message ----- > From: "Mircea Markus" <mmarkus(a)redhat.com&gt; > To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org&gt; > Sent: Thursday, February 9, 2012 6:04:59 PM > Subject: Re: [infinispan-dev] Keeping track of locked nodes > > > > ----- Original Message ----- > > From: "Mircea Markus" <mmarkus(a)redhat.com&gt; > > To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org&gt; > > 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(a)gmail.com&gt; > > > To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org&gt; > > > 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(a)redhat.com&gt; > > > 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.