[infinispan-dev] Hot Rod - pt3

[Alex Kluge]

> Perhaps the events should just be restricted to notifying when a key has changed (i.e., a bit like Invalidation) but with no values/payload passed on, forcing the client to do a GET if the value was required.

 Exactly, we can define the set of events that they can listen for, the end
user only has the choice to subscribe to the events or not. I am most interested in being able to listen for write events. The level of granularity though could use some thought.


 The granularity of the events has also been a topic of discussion.  The end user is likely to want to make the selection at the level of the specific cache, or, perhaps, of keys within a cache. However, I expect that they would be well served with making the selection at the level of the cache, rather than trying to sort out which specific keys they are interested in.

 
 Relevant events should be seen no mater which server you are connected to. I am trying to stay away from implementation details, but I can say that I have done this, and that the cost is not that high.

                                       Alex


--- On Fri, 1/8/10, Manik Surtani <manik at jboss.org> wrote:

> From: Manik Surtani <manik at jboss.org>
> Subject: Re: [infinispan-dev] Hot Rod - pt3
> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
> Date: Friday, January 8, 2010, 7:13 AM
> 
> On 8 Jan 2010, at 13:05, Mircea Markus wrote:
> 
> >> 
> >> I can see how they can be abused to form a
> JMS-like message-passing layer, but then a lot of stuff
> could be open to abuse.  Perhaps the events should just
> be restricted to notifying when a key has changed (i.e., a
> bit like Invalidation) but with no values/payload passed on,
> forcing the client to do a GET if the value was required.
> > Once we have the server->client notification
> mechanism working IMO we should allow the user to decide
> which notifications he wants to listen to, and not be
> restrictive about it. Re:key change notifications, I'm not
> sure that will work with the current ISP architecture: right
> now the notifications are local, i.e. one will only be
> notified by the keys changed in the local cache. So if a
> used want to be notified when the "account" key changed,
> that will only happen if he is connected to the server on
> which the "account" key was hashed.  Even more, if he
> will connect to another server, which contains "account",
> the notification behavior might be different, which might be
> confusing.  
> > Not a protocol design expert, but is it common for
> this "push" approach for protocols? 
> 
> 
> Well, any form of notification beyond keys would be much
> too expensive.  Although this can be hidden from the
> user by using a proxy Event object which has a key but
> lazily loads the value when Event.getValue() is invoked.
> 
> Re: the global scope of events, this is
> important/interesting.
> 
> Client ----> ServerA, ServerB, ServerC ... Server Z
> 
> Assuming the client has a connection to A, and registers
> interest in keys k1... k3, you are correct that ServerA
> would only be aware of changes on keys located on ServerA
> and not globally.  Solutions may be that ServerA acts
> as a proxy for the Client and registers for events on other
> servers on the clients' behalf?  No simple answers here
> I'm afraid... 
> 
> Cheers
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
> 
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>