Second level cache providers now have the option to use custom key implementations.
This was done as the default key implementation is very generic and is quite
a large object to allocate in large quantities at runtime.
In some extreme cases, for example when the hit ratio is very low, this was making the efficiency
penalty vs its benefits tradeoff questionable.
Depending on configuration settings there might be opportunities to
use simpler key implementations, for example when multi-tenancy is not being used to
avoid the tenant identifier, or when a cache instance is entirely dedicated to a single type
to use the primary id only, skipping the role or entity name.
Even with multiple types sharing the same cache, their identifiers could be of the same
Type; in this case the cache container could
use a single type reference to implement a custom equality function without having
to look it up on each equality check: that's a small optimisation but the
equality function is often invoked extremely frequently.
Another reason is to make it more convenient to implement custom serialization protocols when the
implementation supports clustering.