2011/5/25 Mircea Markus <mircea.markus(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev