On Fri, Jan 20, 2012 at 2:54 PM, Sanne Grinovero <sa...@infinispan.org> wrote: > On 20 January 2012 12:41, Mircea Markus <mircea.mar...@jboss.com> wrote: >>>>> Cool. Mircea, reckon we can patch this quickly and with low risk? Or is >>>>> it high risk at this stage? >>>> I don't think it's a good moment for this right now. I'm not even >>>> convinced that this is the way go, as it might be cheaper to cache this >>>> information than to calculate it when needed. >>> >>> Just to clarify, I wasn't reporting a contention point or a >>> performance issue. I was just puzzled by the design as it's very >>> different than what I was expecting. I think we should move towards a >>> design for which we don't really consider the locks to be positioned >>> on a specific node, they should be free to move around (still >>> deterministically, I mean on rehash). >>> Not asking for urgent changes! >> +1, you've been quite convincing about this in Lisbon :-) >> However ATM the lock failover is mainly managed by the transaction >> originator and is not migrated across during topology changes. > > So if locks are failed-over, is your transaction originator able to > find the new owner to unlock it? That's the core of my question on > keeping the Address.. not performance related. >
Actual locks are only maintained on the primary owner. The other owners keep a "backup lock", in the sense that all the transactions that have prepared on a node are presumed to have acquired the lock on the primary node (even if they did not). When the primary owner changes, the new owner searches for such backup locks and doesn't allow any transactions to acquire that lock as long as it has any backup locks. The originator determines the new owners according to the new CH and sends the commit or rollback command to all of them. 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. Mircea, perhaps an update of https://community.jboss.org/wiki/SingleNodeLockingModel is in order? ;-) _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
