[infinispan-dev] Keeping track of locked nodes

[Dan Berindei]

On Thu, Feb 9, 2012 at 8:10 PM, Mircea Markus <mmarkus at redhat.com> wrote:
> 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.

We've committed to implementing NBST for 5.2, so not releasing the ST
lock is not an option.
The only choice then is to transfer the locking information along with
the state.