2011/5/25 Mircea Markus <mircea.mar...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
