Looking for guidance using new CacheInvalidationService

[jekramer]

Our team is working on implementing a global db-cache invalidation solution. We are hoping to make use of the CacheInvalidationService. We've had trouble understanding how to reliably generate a key for the index cache though. It seems like the options require you to know something about how the vertex has been updated on that instance, so if we are sending information from a different node in the cluster, I'm not sure we'll have all the necessary information. If there's something I'm missing there though, please let me know!

We have a few workarounds we can do for now, but I wanted to post them here and see if any are strongly objected to, or if any would be useful for us to contribute back to the project.

Proposed Change Options*:

• Set different activation flags for db index cache and db vertex cache
• Set different cache times for db index cache and db vertex cache
• Skip adding to index cache if a query returns no results

*we are in early stages of using JanusGraph, and the one index we're currently working with has a key that's unlikely to change, so the index cache isn't as important to us right now as the vertex cache

Open to any other suggestions as well! Thanks.

[porunov]

For reference the related discussion about how to invalidate data on other nodes (including how to generate a key for the index cache) is here: #3512

Set different activation flags for db index cache and db vertex cache

+1 for this feature. I believe having an ability to enable just one of those caches instead of enabling them always together makes sense in some cases.

Set different cache times for db index cache and db vertex cache

Also makes sense to me. +1.

Skip adding to index cache if a query returns no results.

Not sure this one is useful if the above features are implemented but don't have any objections about this feature.