[infinispan-dev] singleton @Listeners

[Galder Zamarreño]

On Jul 6, 2012, at 12:44 PM, Mircea Markus wrote:

> ----- Original Message -----
>> From: "Galder Zamarreño" <galder at redhat.com>
>> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
>> Sent: Friday, July 6, 2012 2:46:20 AM
>> Subject: Re: [infinispan-dev] singleton @Listeners
>> 
>> 
>> On Jun 28, 2012, at 11:26 AM, Mircea Markus wrote:
>> 
>>> This is a problem that pops up constantly:
>>> User:      "I add a listener to my distributed/replicated cache but
>>> this gets invoked numOwners times - can I make that to be invoked
>>> only once cluster wise?"
>>> Developer: "Yes, you can! You have to do that and that..."
>>> 
>>> What about a "singleton" attribute on the Listener? Would make the
>>> reply shorter:
>>> Developer: "Use @Listener(singleton=true)"
>> 
>> Hmmm, that seems doable without any extra attributes.
>> 
>> For a replicated cache, take the view and pick a node (consistently
>> 
>> For a distributed cache, find the primary owner of a key.
> That'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'd add this attribute to the listener.
>> 
>> Has this been asked so often? I don't recall right now… :)
> Yes, CBOE had the same issue as they needed to push updates from one cluster to the other over hotrod.
> Also in this article they have to do quite a workaround to enforce uniqueness:  blog.c2b2.co.uk/2012/06/infinispan-event-push-to-tomcat.html

Btw, what that link is doing is implementing a very similar pattern to the near cache pattern I implemented, incidentally, with JMS too :)

The point is: you have a set of client applications that want to receive notifications when cache updates happen.

There's nothing really fancy about it, and it's already included amongst our demos, plus it works for remote caches, not only embedded ones :)

I agree, I might not have banged so much about our near cache demo, but that's because I consider it a bit clumsy (mutliple protocols, need for JMS server, what happens if the server goes down…etc)

> And there were some others :)
> 
>> 
>>> 
>>> Cheers,
>>> Mircea
>>> 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache