Nice work!
Few questions:
- in the context of near-caching, entry-modified and entry-deleted would have the same
effect on the client: invalidation of data. If near-caching is our main goal, we might as
well send a single notification type (entry-modified) for both modification and deletion
(the deletion is just a particular case of modification). Just an idea.
- how does the server know that a request originated from a certain client in order not to
send it to that client again? There's no clientId in the request...
On Nov 12, 2013, at 3:17 PM, Galder ZamarreƱo <galder(a)redhat.com> wrote:
Hi all,
Re:
https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events
I've just finished writing up the Hot Rod remote events design document. Amongst many
other use cases, this will enable near caching use cases with the help of Hot Rod client
callbacks.
Cheers,
--
Galder ZamarreƱo
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (
www.infinispan.org)