<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 18, 2013 at 9:43 AM, Galder Zamarreņo <span dir="ltr"><<a href="mailto:galder@redhat.com" target="_blank">galder@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Nov 14, 2013, at 1:20 PM, Pedro Ruivo <<a href="mailto:pedro@infinispan.org">pedro@infinispan.org</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> Simple question: shouldn't PFER ensure some consistency?<br>
><br>
> I know that PFER is asynchronous but (IMO) it can create inconsistencies<br>
> in the data. the primary owner replicates the PFER follow by a PUT (PFER<br>
> is sent async log the lock is released immediately) for the same key, we<br>
> have no way to be sure if the PFER is delivered after or before in all<br>
> the backup owners.<br>
><br>
> comments?<br>
<br>
</div>Assuming that PFER and PUT happen in the same thread, we're normally relying on the JGroups sequence of events to send the first, wait no response, and then send the second put. That should guarantee order in which puts are received in the other nodes, but after that yeah, there's a risk that it could happen. PFER and PUT for a given key normally happen in the same thread in cache heavy use cases such as Hibernate 2LC, but there's no guarantee.<br>
</blockquote><div><br></div><div>I don't think that's correct. If the cache is synchronous, the PUT will be sent as an OOB message, and as such it can be delivered on the target before the previous PFER command. That's regardless of whether the PFER command was sent as a regular or as an OOB message.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
<div class="im"><br>
><br>
> Pedro<br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
<br>
</div>--<br>
Galder Zamarreņo<br>
<a href="mailto:galder@redhat.com">galder@redhat.com</a><br>
<a href="http://twitter.com/galderz" target="_blank">twitter.com/galderz</a><br>
<br>
Project Lead, Escalante<br>
<a href="http://escalante.io" target="_blank">http://escalante.io</a><br>
<br>
Engineer, Infinispan<br>
<a href="http://infinispan.org" target="_blank">http://infinispan.org</a><br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div></div>