[infinispan-dev] Keeping track of locked nodes

[Mircea Markus]

----- 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. 
There might still be a problem when numOwner=1 though as concurrent write might be applied on C, then overwritten by the original transaction's commit. That's if we don't migrate the prepare state over during state transfer, which I don't think we do?