On Thu, Feb 9, 2012 at 3:07 PM, Mircea Markus <mmar...@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. _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
