Building a better near cache

Question

I'm currently putting some code together to use for frequently updated data. The data set is large enough to warrant a distributed cache, and it will be read frequently by other cluster members than the key owner. To add to this, when the data changes it will trigger some business logic on the cluster members that had previously read the data.
In effect, it is a distributed cache in which clients can subscribe to particular keys to be notified when the underlying data changes.
The data is volatile and has very high update frequency so there's no point in backing it up on a second node, so I've configured a distributed-cache with 0 backups.
I've implemented a working prototype by wrapping a near cache and front-map listener. The wrapper maintains a set of current subscribers for each key, and each time a key is invalidated as per the near-schemes invalidation strategy the value is re-requested if the subscriber set is non empty. This works fine, but I'd like to get rid of the extra invalidate and get packages and instead get the updated value sent directly instead of the invalidation.
So here's a couple of questions:
1) Is it possible to get this behaviour from a near cache out of the box (docs are slightly vague, and I haven't been able to get it to work by trial and error)
2) If I were to stop using a near-cache and register a map listener for the keys directly on the distributed cache:
a) is the key match evaluated on the object form or the binary representation of the cached key - I'm concerned about the cpu overhead when deserialising the keys?
b) if there's more than one listener for the specified key, will the update package be sent using unicast or multicast?

Answer 1

Hi Henric,
I gave some thinking on this since yesterday.
It might be worth investigating to see if you could override the listener handling and registration methods which near cache uses so that you could use whatever notifications are sent anyway.
1. : I can't answer this at the moment.
2. a: I believe the key match is done on the binary key. I don't see any reason why not to use the binary key.
2. b: I think it depends on how many listeners. Look at the documentation of the multicast-threshold-percent setting within the multicast-listener configuration.
Best regards,
Robert