SimpleKey contains invalid hashcode on deserialization when parameters include an enum #24320
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm working on an application that uses Spring caching and replicates cache entries across a cluster of hosts. When one host adds a new entry to a cache, it serializes that cache entry and sends it to the other hosts for them to add too.
I noticed an issue where if an enum type is a part of the cache key the cache will not replicate properly. Each host winds up with duplicate entries in the cache for identical-looking keys.
I traced the issue to the SimpleKey's hashCode field. It gets initialized in the SimpleKey's constructor and is based on the hash codes of all of the SimpleKey's parameters. The problem is that enum hash codes are based on object identity - they aren't consistent from one host to another and will even change with an application restart. If a SimpleKey instance was deserialized from another host and contains an enum parameter, then its hashCode field will have a different value than a SimpleKey with the same parameters created by the current host.
This means that even though the replication is working - each host is adding cache entries sent from other hosts to their own caches - no host can ever get a cache hit on an entry that was sent to it from another. The different hash codes make the cache's underlying map lookups fail to find the already-existing keys. The ultimate consequence is that these caches effectively have no synchronization across hosts and they're bloated with up to one duplicate entry per host for common keys.
This pull request fixes the issue by making the SimpleKey's hashCode transient so it isn't shared with other runtimes when serialized, and by making sure its hashCode gets calculated by its own runtime even when the object was deserialized instead of constructed.
I think this is a reasonable change because identity-based hashcodes are a real possibility in Java (it's the Object.hashCode implementation) and since SimpleKey derives its hash code from a set of parameters of unknown types you can't assume it's safe to share when serializing.