[infinispan-dev] Order of locking in optimistic tx cache

[Pedro Ruivo]

Hi,

On 29-01-2018 17:42, Radim Vansa wrote:
> Hi Pedro,
> 
> I have a looong open JIRA [1] and so I've tried to look into current
> ordering of locks. And I've noticed that we don't sort the keys anymore
> but have a short 'big lock' [2] - I don't fully understand it, though.
> What happens if T1 has A locked and T2 tries to lock A and B? Is T2
> allowed to acquire lock on B and waits for A? 

T2 is allowed to acquire B but has to wait for T1 until it is ready to 
proceed.

 > Are the locks 'fair' and the synchronized block introduces an 
ordering on the lock requests?

The main reason of the block is to avoid deadlocks. Using your example, 
the thread handling T2 won't block for A to be available and continues 
trying to acquire the remaining lock.

Also, it has the benefit of ordering contented transactions and provides 
fairness

Pedro

> 
> Thanks
> 
> Radim
> 
> [1] https://issues.jboss.org/browse/ISPN-2491
> 
> [2]
> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/util/concurrent/locks/impl/DefaultLockManager.java#L115
>