<div class="gmail_quote">On Fri, Jul 6, 2012 at 1:44 PM, Mircea Markus <span dir="ltr">&lt;<a href="mailto:mmarkus@redhat.com" target="_blank">mmarkus@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">----- Original Message -----<br>
&gt; From: &quot;Galder Zamarreño&quot; &lt;<a href="mailto:galder@redhat.com">galder@redhat.com</a>&gt;<br>
&gt; To: &quot;infinispan -Dev List&quot; &lt;<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a>&gt;<br>
</div><div class="im">&gt; Sent: Friday, July 6, 2012 2:46:20 AM<br>
&gt; Subject: Re: [infinispan-dev] singleton @Listeners<br>
&gt;<br>
&gt;<br>
</div><div class="im">&gt; On Jun 28, 2012, at 11:26 AM, Mircea Markus wrote:<br>
&gt;<br>
&gt; &gt; This is a problem that pops up constantly:<br>
&gt; &gt; User:      &quot;I add a listener to my distributed/replicated cache but<br>
&gt; &gt; this gets invoked numOwners times - can I make that to be invoked<br>
&gt; &gt; only once cluster wise?&quot;<br>
&gt; &gt; Developer: &quot;Yes, you can! You have to do that and that...&quot;<br>
&gt; &gt;<br>
&gt; &gt; What about a &quot;singleton&quot; attribute on the Listener? Would make the<br>
&gt; &gt; reply shorter:<br>
&gt; &gt; Developer: &quot;Use @Listener(singleton=true)&quot;<br>
&gt;<br>
&gt; Hmmm, that seems doable without any extra attributes.<br>
&gt;<br>
&gt; For a replicated cache, take the view and pick a node (consistently<br>
&gt;<br>
</div><div class="im">&gt; For a distributed cache, find the primary owner of a key.<br>
</div>That&#39;s pretty much how I had in mind to implement it. But I think the attribute is needed though: there are use cases in which you still want to be notified on all the owners, as you do now. OTOH if you only want a per-cluster notification you&#39;d add this attribute to the listener.<br>

<div class="im">&gt;<br></div></blockquote><div><br>If we add the attribute we&#39;re going to raise some new questions:<br>* Is the listener guaranteed to fire on the primary owner?<br>* If two keys are Group-ed together, is the listener guaranteed to fire on the same node for both keys? What if a new node becomes the primary owner between the two modifications?<br>
* If the key is modified by the same put command on two owners, and each node is the primary owner of the key at the moment when it receives the put command, does the listener fire on still fire only once?<br><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">
&gt; Has this been asked so often? I don&#39;t recall right now… :)<br>
</div>Yes, CBOE had the same issue as they needed to push updates from one cluster to the other over hotrod.<br>
Also in this article they have to do quite a workaround to enforce uniqueness:  <a href="http://blog.c2b2.co.uk/2012/06/infinispan-event-push-to-tomcat.html" target="_blank">blog.c2b2.co.uk/2012/06/infinispan-event-push-to-tomcat.html</a><br>

And there were some others :)<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br>I think what C2B2 are doing is more like replicated listeners in a distributed cache. They probably had to post the message on JMS only from the primary owner, but the blog doesn&#39;t mention it, so I don&#39;t think it was that hard to figure it out ;)<br>
</div></div><br>Cheers<br>Dan<br><br>