[infinispan-dev] singleton @Listeners

[Dan Berindei]

On Mon, Jul 9, 2012 at 5:52 PM, Galder Zamarreño <galder at redhat.com> wrote:

>
> 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
> > And there were some others :)
>
> Ok. I'm thinking about the priority of this.
>
> I think our listeners are very buggy, as I've already ranted a few times
> (thread safety guarantees, plus rather akward programming model), but the
> agreement was to not touch them till we get around to implementing JSR-107
> notifications.
>
> So, I think what we should do now is:
>
> 1. Document the patterns to get around the problem that you explain.
>
> 2. Hold of implementing any new listener functionality cos it's quite
> likely gonna need reimplementing one way or the other when we get around to
> JSR-107
>
> My 2 pesetas :)
>
>
+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20120710/57abf668/attachment.html