On 17 Apr 2014, at 08:03, Radim Vansa
<rvansa@redhat.com> wrote:
On 04/16/2014 05:38 PM, William Burns wrote:
On Wed, Apr 16, 2014 at 11:14 AM, Galder
Zamarreño <galder@redhat.com> wrote:
On 11 Apr 2014, at 15:25, Radim Vansa
<rvansa@redhat.com> wrote:
OK, now I get the picture. Every time we
register to a node (whether the first time or after
previous node crash), we receive all (filtered) keys
from the whole cache, along with versions. Optionally
values as well.
Exactly.
In case that multiple modifications happen
in the time window before registering to the new
cache, we don't get the notification for them, just
again the whole cache and it's up to application to
decide whether there was no modification or some
modifications.
I’m yet to decide on the type of event exactly here,
whether cache entry created, cache entry modified or a
different one, but regardless, you’d get the key and the
server side version associated with that key. A user
provided client listener implementation could detect
which keys’ versions have changed and react to that,
i.e. lazily fetch new values. One such user provided
client listener implementation could be a listener that
maintains a near cache for example.
My current code was planning on raising a
CacheEntryCreatedEvent in this case. I didn't see any
special reason to require a new event type, unless anyone
can think of a use case?
When the code cannot rely on the fact that created = (null
-> some) and modified = (some -> some), it seems to me
that the user will have to handle the events in the same
way. I don't see the reason to differentiate between them in
protocol anyway. One problem that has come to my mind: what
about removed entries? If you push the keyset to the client,
without marking start and end of these events (and expecting
the client to fire removed events for all not mentioned keys
internally), the client can miss some entry deletion
forever. Are the tombstones planned for any particular
version of Infinispan?
That’s a good reason why a different event type might be
useful. By receiving a special cache entry event when keys are
being looped, it can detect that a keyset is being returned,
for example, if the server went down and the Hot Rod client
transparently failed over to a different node and re-added the
client listener. The user of the client, say a near cache,
when it receives the first of this special event, it can make
a decision to say, clear the near cache contents, since it
might have missed some events.
The different event type gets around the need for a start/end
event. The first time the special event is received, that’s
your start, and when you receive something other than the
special event, that’s the end, and normal operation is back in
place.
WDYT?