[infinispan-dev] Hot Rod - pt3

Galder Zamarreno galder at redhat.com
Tue Jan 12 06:16:59 EST 2010



On 01/08/2010 08:26 PM, Alex Kluge wrote:
>> 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.

Just to make sure we're all in the same page. I don't expect to specify 
key change related events for the moment.

Right now, the primary use case that I see is sending back cluster 
formation changes, rather than passing this back as part of response. 
This would allow for clients to subscribe to them depending on their 
capabilities.

However, events will be specified in such way that allow for easy 
extension for other use cases mentioned.

Do we all agree with this?

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


More information about the infinispan-dev mailing list