On 17 Apr 2014, at 08:03, Radim Vansa <[email protected]> wrote:
On 04/16/2014 05:38 PM, William Burns wrote:
On Wed, Apr 16, 2014 at 11:14 AM, Galder Zamarreño
<[email protected]> wrote:
On 11 Apr 2014, at 15:25, Radim Vansa <[email protected]>
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?
