<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 18 Mar 2009, at 14:07, Jason T. Greene wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Manik Surtani wrote:<br><blockquote type="cite">On 18 Mar 2009, at 13:54, Jason T. Greene wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">Manik Surtani wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On 17 Mar 2009, at 20:33, Jason T. Greene wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Brian Stansberry wrote:<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">However, this sounds like a problem with PFER. If someone calls PFER, I think the original transaction should resync the node snapshot.<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">How would this be done? AFAIK the application has no control over the data in JBCs transaction context.<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The PFER implementation, not the application, would just drop the node from the tx context which invoked pfer. That would mean that any subsequent read would fetch the most current data.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">No, that is not correct. PFER suspends ongoing TXs and runs outside of any TX, to prevent a failure rolling back the TX. And this is the root of the problem.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">"correctness" I think is in the eye of the beholder :)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">To me it does not seem correct that i can do<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">pfer(k, 7)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">get(k) == null<br></blockquote></blockquote><blockquote type="cite">The above would only happen if you did:<br></blockquote><blockquote type="cite">tx.start() // ensure this in a transactional context<br></blockquote><blockquote type="cite">assert get(k) == null // initially empty<br></blockquote><blockquote type="cite">pfer(k, 7) // this *always* happens outside of the context of a tx<br></blockquote><blockquote type="cite">assert get(k) == null // this still holds true since we initially read this as a null.<br></blockquote><br>Yep<br></div></blockquote><div><br></div><div>And I would say that this is expected since pfer is clearly documented as an operation that happens outside of the current transactional context.</div><div><br></div><div>Of course, we *could* hack it to provide more natural behaviour in *some* cases, by actually tracking any ongoing transaction, suspending it, completing the pfer, and if the pfer is successful remove any cached nodes in the *original* transaction's context so this is refreshed. But this will only work if the node has not been first modified by the transaction, otherwise you will end up either losing changes made by the transaction, or flushing transaction changes prematurely.</div><div><br></div><div>E..g., this case:</div><div><br></div><div>get(fqn, k) == null</div><div>put(fqn, k1, 1)</div><div>pfer(fqn, k2, 2)</div><div><br></div><div>If we only deal with some cases (node not modified before pfer) and not others, that would lead to even more confusion in what is and is not expected behaviour. :-)</div><br><blockquote type="cite"><div><br><blockquote type="cite">Anyway, this pattern has nothing to do with the problem at hand, or the correctness/consistency I discussed, which has to do with handling a remove() on a null entry with repeatable read.<br></blockquote><br>Sure, remove was also broken, which fixing the above would have hidden (since the issues are related). However, that doesn't mean this should not be addressed at some point.<br><br>-- <br>Jason T. Greene<br>JBoss, a division of Red Hat<br></div></blockquote></div><br><div apple-content-edited="true"> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>--</div><div>Manik Surtani</div><div>Lead, JBoss Cache</div><div><a href="http://www.jbosscache.org">http://www.jbosscache.org</a><br><a href="mailto:manik@jboss.org" target="_blank">manik@jboss.org</a></div><div><br></div></div></span><br class="Apple-interchange-newline"></div></span><br class="Apple-interchange-newline"> </div><br></body></html>