<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Is this related?<div><br></div><div><a href="https://jira.jboss.org/browse/ISPN-595">https://jira.jboss.org/browse/ISPN-595</a></div><div><br></div><div>Lets have a chat when you're online later today...</div><div><a href="https://jira.jboss.org/browse/ISPN-595"></a><br><div><div>On 23 Nov 2010, at 10:34, Manik Surtani wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br>On 22 Nov 2010, at 20:24, Vladimir Blagojevic wrote:<br><br><blockquote type="cite">Well we have L1 data in the same container as all other data and as such <br></blockquote><blockquote type="cite">is treated no different that non-L1 data - including locking.<br></blockquote><br>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... <br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">On 10-11-22 1:55 PM, Manik Surtani wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">However I'm puzzled that the L1 invalidation kills this - the L1 invalidation should be a fail-fast mechanism.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">infinispan-dev mailing list<br></blockquote><blockquote type="cite"><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br></blockquote><blockquote type="cite"><a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br></blockquote><br>--<br>Manik Surtani<br><a href="mailto:manik@jboss.org">manik@jboss.org</a><br>Lead, Infinispan<br>Lead, JBoss Cache<br>http://www.infinispan.org<br>http://www.jbosscache.org<br><br><br><br><br><br>_______________________________________________<br>infinispan-dev mailing list<br>infinispan-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/infinispan-dev<br></div></blockquote></div><br><div>
<span class="Apple-style-span" style="font-size: 12px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>--</div><div>Manik Surtani</div><div><a href="mailto:manik@jboss.org">manik@jboss.org</a></div><div>Lead, Infinispan</div><div>Lead, JBoss Cache</div><div><a href="http://www.infinispan.org">http://www.infinispan.org</a></div><div><a href="http://www.jbosscache.org">http://www.jbosscache.org</a></div><div><br></div></div></span><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br></div></body></html>