[infinispan-dev] put if absent not atomic: https://jira.jboss.org/jira/browse/ISPN-236

[Mircea Markus]

On Oct 24, 2009, at 1:11 AM, Sanne Grinovero wrote:

> Hi,
> Please note that the tests running in REPL_SYNC mode are not failing
> anymore, just DIST is still failing.
They are falling on my laptop, and I would expect them to fail for the  
reason mentioned in this email. Aren't you talking about  
LocalISPNCacheTestFactory which was fixed?
>
> I've ported the test to core, as agreed in group "stress" as it's slow
> so it's not starting automatically:
>
> mvn test -Dtest=org.infinispan.stress.PutIfAbsentStressTest
>
> Please have a look to the different configurations I've set it to
> test; it should be trivial to add more configurations you might want
> to check.
>
> thanks for all the support,
> Regards,
> Sanne
>
> 2009/10/23 Mircea Markus <mircea.markus at jboss.com>:
>> Hi Manik,
>>
>> While the fix I made for EntityWrapper fixed the cache in local mode,
>> the replicated mode[1] (pretty sure dist is the same) is far from
>> working.
>> The issue is the following:
>> node1.put(k,v2) :: WL(k1) -> releaseLock(k1) -> replicate(k1) ->
>> incoming_thread_performs put (k, *v2*)
>> node2.put(k,v2) :: WL(k2) -> releaseLock(k2) -> replicate(k2) ->
>> incoming_thread_performs put (k, *v1*)
>>
>> now in this scenario both operation succeed! This is caused by the
>> fact that lock interceptor is *after* repl interceptor in the chain,
>> so when repl is triggered the key is no longer locked.
>> In other words, if the puts happen at the same time, on the same key
>> then both might succeed, leaving the cluster in an inconsistent  
>> state.
>> IMO, the correct approach would be to keep the lock while doing the
>> replication. This would reduce the concurrency though, as locks would
>> be held for longer amounts of time. But the data consistency would
>> increase. (this would be an easy fix for Repl, but dist relies on
>> interceptor's order).
>>
>> I've also tried doing the call within a tx, but there's a deadlock -
>> I'll investigate this on Mon.
>>
>> [1] I know disyt is what we'll use but problem exists for repl as  
>> well
>>
>> Cheers,
>> Mircea
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev