[infinispan-dev] locking optimisations reloaded

[Sanne Grinovero]

2011/5/25 Mircea Markus <mircea.markus at jboss.com>:
>
> 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'd also point out that you get the same result even if both threads
are running transactions: the final state depends to who commits last;
in your example you could interpret that step "2." is doing a put for
value B and committing as well.

>
> 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 agree, this is the current state.

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