Cache search capability

Question

Hi,
I have the following questions on querying the cache:
1.) performance of key searches as compared to entity searches; here we use the entity attribute as the key so instead of searching the entities I am wondering if there is a benefit to search the keys.
2.) multiple attribute entity searches; it is not clear from the API if one can construct filters that look/compare multiple attributes.
Thanks,
Adrian

Answer 1

You can use the AndFilter, OrFilter, AnyFilter andAllFilter classes to compose
logical expressions from multiple filters and thosefilters need not use the same
attribute. The only restriction is that the filterswill always filter the same cache,
therefore you cannot have single-pass searchesspanning multiple named caches.
Depends on the volume of objects you filtering, you
might get better performance by implement your own
extractor class instead of multipe filters with
reflection invoke.
I feel that you demonize reflection a bit. Reflection in itself is not necessarily a big cost, if it is done correctly. In general, if you do not do the introspection parts all the time, instead you cache the Method object, then the overhead is not that high. Of course in a fit-all solution you cannot assume that your objects will all be in the same class, therefore you have to do additional checks to ensure that you always use the correct Method object.
However, if you get to the point of actually using reflection in a filter working on a distributed cache, that means that you are iterating over the cache one-by-one and you had to deserialize the object, and that is even more expensive than reflection.
The fastest way to filter a cache is always having indexes on the filtered-by attributes. And in this case reflection is employed only at the single time of putting the value into the backing map, but accessing the index does NOT need reflection.
So, yes, if you have to filter your entries one-by-one, then a custom filter can be faster than the reflection-based out-of-the-box filters, but at that point you already had to make a much larger performance sacrifice.
However, the drawback is that you'd need to deploy
your customized class to each node, though.Or you can use a properly written (meaning it caches the precompiled script, by script text to ensure that it is not necessary to recompile it every time you run the filter with the same script) scripting-language-based filter class (e.g. a Groovy-based one).
I don't know if there is going to be one in 3.4, but I wouldn't be surprised to see one, and anyway, even if it is not included, it is not particularly difficult to write one.
Best regards,
Robert