|
|
|
|
|
|
If I would like to allow second level cache providers the option to use custom key implementations.
The current 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
{{org.hibernate.type.Type}}; in this case the cache container could
use a single {{Type}} reference to implement a custom equality function without having
to look up the {{Type}} on each equality check: that's a small optimisation but the
equality function is invoked extremely frequently in many practical configurations.
Another reason is to make it more convenient to implement custom serialization protocols when the implementation supports clustering.
It might open the doors to more complex improvements, like HHH-9780.
|
|
|
|
|
|
