• Bug
  • Status: Open
  • 2 Major
  • Resolution:
  • cdennis
  • Reporter: ayreon
  • January 13, 2010
  • 1
  • Watchers: 2
  • September 20, 2012

Description

However in the standard non-clustered mode of EHCache the hashCode() and equals() methods of the key are used to check if the particular key is in the cache or not, it is not true in TC clustered mode (nor in indentity, neither in serialization mode),but in clustered mode the serialized value of the key (a String) is used instead of the standard hashCode + equals,

I think it’s acceptable to serialize the key (however as i know (according to the docs) it’s not a requirement for the key the be Serializable in identity mode, I’ve opened another issue for this), but comparing the serialized values when getting an element from the cache is a questionable idea since following this approach all the existing algorithms based on complex key’s hashCode and equals should be rewritten if somebody wants to enable TC clustering for an existing app… but at least it should be stated somewhere in a doc if it is the desired behaviour.

It means that currently in our application the TC clustering cannot be used at all for EHCache, since we heavily rely on hashCode and equals of our complex keys.

Truth is there is a workaround for this particular problem.

e.g. if we have a key class:

class Foo { int a; int b;

[hashCode and equals methods, considering only “int a”]

}

the class ccould be refactored marking “int b” transient, hence when the current TC implementation compares the serialized keys it will work perfectly. so it could be a workaround for us

BUT we also use in our implementation the cache.getKeys() method , and this method returns the list of the serialized keys (!) as Strings (even in identity mode), and on the top of that i’m not able to deserialize those mighty strings, because your serializer uses its own way to serialize the keys, so i cannot restore them anymore

So i think this problem is a critical one, because currently complex keys cannot be used at all safely in a TC clustered EHCache.

Versions: EHCache 1.7.2 (same problem with 1.7.1) TC 3.2.0 (same problem with 3.1.1) tim-ehcache-1.7 1.5.0 (and all its dependencies)

Comments

Chris Dennis 2010-01-15

I’ve solved CDV-1445 which now allows non-serializable keys to be used in an identity mode TC clustered EhCache. This means that key comparison for EhCache instances will now use equals as would be normal for a regular map implementation.

Solving this issue for serialization mode caches would be significantly more complicated. Currently to minimize the cost of lookups we convert the querying key to its serialized form, and then perform the lookup against the serialized forms in the map. In order to maintain the equals contract we would have to deserialize the keys in the map instead. I can imagine it being possible to optimize this (one obvious way being to encode the hashcode of the original key in the serialized form so that the deserializations can be limited to those keys with matching hashcodes), but even so I imagine this would still be quite costly in terms of performance, or at best would be very hard to write with having to bleed code down into tim-concurrent-collections.

Janos Biro 2010-01-16

https://jira.terracotta.org/jira/browse/CDV-1444?focusedCommentId=41246&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_41246

Steve Harris 2010-01-21

Seems the solution to this is going to require a bit more thought. Moving to taraval

Robert Howes 2010-07-23

We have just encountered this issue and I agree that irrespective of whether this is desired TC behaviour more documentation is needed to explain the risks of using complex keys with Terracotta distributed caches.

I see that this has been open for 6 months now - any comments on timelines and intended fix? Is the behaviour going to change to be consistent with non-TC ehcache or left as is with more explicit documentation?

Chris Dennis 2011-01-11

With the added complications of DCV2 this is now an even more complicated problem (requires changes in both the server and the client). What’s more there is still disagreement internally about how best to solve this, along with some doubt about what performance impact implementing most of the ‘obvious’ solutions would have on the regular currently unaffected user. Punting to Ulloa until we can get some consensus on these issues.

Kunal Bhasin 2011-05-20

IGIndex have run into this as well.