Re: [infinispan-dev] Keeping track of locked nodes
On Fri, Jan 20, 2012 at 2:54 PM, Sanne Grinovero <sanne(a)infinispan.org> wrote:
On 20 January 2012 12:41, Mircea Markus
<mircea.markus(a)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?
;-)