Hello!
Usually it is not wise to have large complex keys, especially ones that you do not control. Can cause all sorts of issues. You can declare your key Externalizable, though, and have control over its marshalling. That, or Binarylizable. Then you get to decide how everything is processed. Regards, чт, 20 июн. 2019 г., 17:45 Axel Faust <[email protected]>: > 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 > >
