Let me detail on this a little more: the optimisation refers to
cache.lock() not to perform remote locks on ALL data owners, but only on the main data
owner.
This way , if session affinity is used for enforcing key locality then cache.lock() would
only acquire lock within the same JVM - i.e. very good performance without loosing
eager's locking semantics. If the cluster changes, and the key is rehashed on a
different node, than eager locking would do an RPC - but for many clusters the topology
changes are infrequent.
Another problem that raises is that of consistency during node failures: if K is on node
A and it was locked by a tx originated on node B. If A fails then we can invalidate the
transaction on B, so that it would rollback.
Another interesting race condition Sanne raised is with re-hashing: "it needs to be
atomic to know who is the owner and aquire the lock, or the owner might be moved and
you're locking on the wrong node (only)"
I think this is not related to this optimisation in particular, but stands for eager
locking in general - any idea how this is handled btw?
Cheers,
Mircea
On 20 Aug 2010, at 11:04, Manik Surtani wrote:
> Not sure I understand - are you proposing that the RPC for LockControlCommands are
always async if the keys are generated using the key affinity service?
>
> On 19 Aug 2010, at 16:29, Mircea Markus wrote:
>
>> Hi,
>>
>> Here is the scenario, N=numOwners
>>
>> TM.start()
>> c.lock(a); //this makes N (might me less) RPCs to acquire locks
>> c.get(a)
>> ...
>> TM.commit(); // this would do an N calls for prepare/commit. Might happen async.
>>
>> By using the key affinity service, one might enforce a tx to operate on
"local" keys (i.e. keys that are hashed on the same node where the tx was
started).
>> Now, if we would be able to *only* eager lock the main data owner (v.s. N RPCs
for lock acquisition locks) than eager locking would be as fast as the non-eager locking
for this scenario.
>> What happens with the TX if the data owner crashes and only one copy is locked?
We would need to invalidate the transaction at originator's side, which I think is
possible.
>> For async repl with N >= 2 and key affinity the performance benefit for eager
locking would be close to local puts: which is huge.
>>
>> This use case was brought by Erik ( cc)- please add you comments if something is
missing. What do you think about this optimisation?
>>
>> Cheers,
>> Mircea
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik(a)jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
>
http://www.infinispan.org
>
http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev