OnRemoveByHandler should include the item that was removed. Unless there is another way to get it?

[arrkaye]

[MichaConrad]

No, that's not going to happen unfortunately ;)

a) The CacheManager events are not supposed to transport the actual cache item (that's primarily my design decision)
b) It is simply not possible because some cache vendors don't support that either.
Meaning, the item was already removed and I cannot pass it through the event chain.

I know that I could implement something like that for most the in memory caches, but not for Redis for example.
I don't think it would be a good idea to return the item in some cases and not in others. That would cause all kinds of confusion...

[arrkaye]

Agreed that it should be consistent.

With regards to these events, if we have multiple instances of a server sharing a Redis cache, and we want only one instance to handle the remove/expiry event, how could we achieve this?

Presumably they would all receive the OnRemoveByHandler event?

[MichaConrad]

@riazkarim That's a tricky one but a common problem for apps which scale and do stuff in parallel.

One simple option would be to only have one instance configured to listen to those events. You have to explicitly enable the feature for the redis cache handle in CacheManager via the KeyspaceNotificationsEnabled property anyways => have that one enabled only once.

Another solution would be implementing a distributed worker queue or at least a lock,
The most simple one could be implemented with CacheManager, like:

• Try to Add a new key to Redis which represents a lock to your old key, like _lock_{oldkey}.
• If the Add operation was successful, go ahead and do the work...
  • All other instances which got triggered by the event and now also try to Add that key would not be able to, as Add only adds new key if it doesn't exist already.
• At the end, the "winner" process can remove the lock key (maybe also give it a short expiration, so that in case the process fails to remove it, because of an error, the key is not locked forever...)

[arrkaye]

@MichaCo Thanks very much. I think your second solution is neat. I'm going to go with that.

[MichaConrad]

@riazkarim FYI, I thought about your initial question a little bit more and I think in this case it is actually fine to be a little bit inconsistent. Actually only the Redis event fired via keyspace event will not support passing back the initial value. In all other scenarios it just works.

I've just added the implementation and did some testing, seems to work.
If you want, give it a try with the beta packages on myget v1.0.1-beta-1487 or greater.

[arrkaye]

@MichaCo Brilliant! Thank you. It works as expected.