Re: [infinispan-dev] Keeping track of locked nodes
----- Original Message -----
From: "Dan Berindei" <dan.berindei(a)gmail.com>
To: "infinispan -Dev List" <infinispan-dev(a)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(a)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?