[infinispan-dev] Keeping track of locked nodes

[Mircea Markus]

----- 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.