[infinispan-dev] singleton @Listeners

[Dan Berindei]

On Fri, Jul 6, 2012 at 1:44 PM, Mircea Markus <mmarkus at redhat.com> 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.
> >
>

If we add the attribute we're going to raise some new questions:
* Is the listener guaranteed to fire on the primary owner?
* 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?
* 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?



> > 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
> And there were some others :)
>
>
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't mention it, so I don't think it was
that hard to figure it out ;)

Cheers
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20120706/badd9c3e/attachment.html