[infinispan-dev] Keeping track of locked nodes

[Dan Berindei]

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.