[infinispan-dev] SingleJoinTest#testTransactional failure

[Manik Surtani]

Is this related?

https://jira.jboss.org/browse/ISPN-595

Lets have a chat when you're online later today...

On 23 Nov 2010, at 10:34, Manik Surtani wrote:

> 
> On 22 Nov 2010, at 20:24, Vladimir Blagojevic wrote:
> 
>> Well we have L1 data in the same container as all other data and as such 
>> is treated no different that non-L1 data - including locking.
> 
> So the issue is that a reader has locked the entry in memory because it is in L1, and this is why the transactional write from elsewhere cannot be applied?  Readers don't block writers... 
> 
>> 
>> On 10-11-22 1:55 PM, Manik Surtani wrote:
>>> I wrote the original test, to simulate a transactional write occuring (still in prepare phase) while a node joins.  So to this end, I think we can safely run the test without L1 caching as the behaviour we are trying to test is still correct.
>>> 
>>> However I'm puzzled that the L1 invalidation kills this - the L1 invalidation should be a fail-fast mechanism.
>>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
> 
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20101123/d04ff124/attachment.html