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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik@jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org





_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev