[infinispan-dev] locking optimisations reloaded

[Galder Zamarreño]

On May 25, 2011, at 1:18 PM, Mircea Markus wrote:

> 
> On 25 May 2011, at 09:12, Galder Zamarreño wrote:
> 
>> 
>> On May 24, 2011, at 11:36 PM, Mircea Markus wrote:
>> 
>>> Hi,
>>> 
>>> This is re: http://community.jboss.org/wiki/PossibleLockingImprovements
>>> 
>>> I've created JIRAs for the locking optimisations as follows:
>>> 
>>> #1: https://issues.jboss.org/browse/ISPN-1131
>> 
>> For #1, how do you handle this case? (both threads on same node)
>> 
>> 1. Thread-1: does a transactional write on key=K1, value=A
>> 2. Thread-2: non-transactional write on key=K1, value=B // not a problem since Thread-1 has not yet acquired WL
>> 3. Thread-1: prepares, acquires a WL on K1, an overrides key=K1 to contain value=A ?
>> 
>> Since Thread-1 does not acquire WL on the write, concurrent non-transactional writes could be lost, couldn't they? 
> 
> I don't think this is an incorrect behaviour as the transaction isolation semantic is preserved. I'll run it by Jonathan to make sure.
> This is also the case ATM, when you run the two threads on different nodes. Which raises another concern around the current early-locking approach: tx behaviour is influenced by where you run the tx. 
> Ie. with same timing, if you run both transactions on the same node you'll get a different result than when you run transactions on different nodes. 

I can agree that it might not be incorrect behaivour, but the behaivour after this locking changes would be different to how it behaves right now because Thread-2 would not be held up any more and so the outcome might be different. To be clear, right now Thread-1 would acquire a WL and Thread-2 would wait and if Thread-1 applied changes within the lock acquisition timeout, Thread-2 would come and override the changes. In the scenario above, the opposite would happen, Thread-1 would override Thread-2.

So, behaviour changes like this should at least be documented if they end up happening. Or, if this type of code examples are incorrect, document them so that people don't rely on them.

Something that might be worth consider is whether a cache should be allowed to be modified both transactionally and in a non-transactional way. IOW, a way to protect against incorrect code practices like the one above could be the following:

- A transactional cache can only be modified within a transaction under normal circumstances.

- A non transactional cache can only be modified outside a transactional.

I agree that this might be a bit extreme and there could be some cases where this might hinder some use cases, but we could use flags to get around this. The use of flag means that the user has to do a conscious decision to get around the limitation.

Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache