Hello, I have been working on integrating Apache Ignite as a distributed caching layer in the open source edition of the Alfresco Content Services product. As this would be an extension, I don't have full control over the kinds of keys used in cache operations. One default cache in particular is using - among others - a complex cache key object where at least one instance field is not relevant for the purpose of establishing equality. Only when a lookup key object is set to the exact same internal state as the key used for the cache put operation, including the field not relevant for equality, will a cache get operation actually hit the existing entry and return the expected cached value.
I have read in https://apacheignite.readme.io/docs/binary-marshaller#binaryobject-and-cachestore that the Ignite BinaryObject class provides automatic hash code / equals implementation. But I have found no details for how these implementations treat different types of fields, e.g. dependent on modifiers, or how to change the default behaviour without modifying the key class in question. My (maybe naiive) assumption was that, if a value class actually provides a hashCode operation that overrides the Object default, then that would be respected. By looking through the source, I have found the interface BinaryIdentityResolver which sounds like it could be helpful in my case. Unfortunately, since I can never know in advance what types of objects users of my extension will use as keys, I can hardly configure a custom binary type configuration for all possible / potential classes. Is there any other way to deal with this kind of situation? For reference, the following GitHub Gist contains the simple unit test I set up to verify this was an issue with Ignite handling of cache keys and not something in my implementation on top of Ignite: https://gist.github.com/AFaust/e52ca1008a71b3e386a34f0fa63274be Regards Axel Faust
