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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev