1:26 p.m.
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(a)jboss.org> wrote:
From: Manik Surtani <manik(a)jboss.org>
Subject: Re: [infinispan-dev] Hot Rod - pt3
To: "infinispan -Dev List" <infinispan-dev(a)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(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev