Question

We are experiencing an odd problem. We get the KeySet of an Oracle Coherence cache, but cannot straight-forwardly get the values from the cache, even with no update activity on it.

The following code fails consistently (i.e. outputs “>>>>NULL” because the object is not retrieved). The question is: WHY?

    NamedCache nc = CacheFactory.getCache(cacheName);
    Set<Object> keys = (Set<Object>)nc.keySet();
    for ( Object key : keys ) {
        Object o = nc.get(key);
        if ( o == null ) {
            System.out.println(">>>>NULL:"+keyStr);
        } 
    }

The cache is a partitioned named cache with multiple indices.

The key is an object (not shown) with one instance variable, a HashMap.

The key object also has equals() and hashCode() methods as follows:

@Override
public int hashCode() {
    final int prime = 31;
    int result = 1;
    result = prime * result + ((values == null) ? 0 : values.hashCode());
    return result;
}


@Override
public boolean equals(Object obj) {
    System.out.println("EQUALS");
    if (this == obj)
        return true;
    if (obj == null)
        return false;
    if (getClass() != obj.getClass())
        return false;
    AbstractCacheKey other = (AbstractCacheKey) obj;
    if (values == null) {
        if (other.values != null)
            return false;
    } else if (!values.equals(other.values))
        return false;
    return true;
}

I believe Coherence uses the hash of the serialized key object in this configuration, which would render these two methods irrelevant, except I don’t know this is true for both front cache (local JVM, has localstorage turned off) and back cache (storage node JVM’s).

Some of our code partially solves this problem by rebuilding the key, inserting the values in a standard order. This usually works. I don’t see why this is necessary, since our hashCode() method and Java’s hashCode() for HashMap are, AFAIK, insensitive to the iteration order of the hash. Why it usually, but not always works is also a mystery.

Answer 1

The answer (thanks, Dimitri) is that the HashMap doesn’t guarantee its serialization ordering, so serialized-hash->deserialize->object-hash->serialize->serialized-hash may result in the second serialized hash being a different byte stream than the first.

Java makes no guarantees about ordering in a hash, and serialization is dependent on ordering. Serialization can be different from one JVM to anther, and even within the same JVM. Since the internal implementation of a HashMap is a typical in-memory hash, with N buckets, each holding (probably via a linked list) a set of entries whose hash corresponds to the bucket, the order in which entries are put into the hash determines (in a non-specified way) the order in which the keyset iteration will return them. A TreeMap, by comparison, should produce consistent ordering and thus, presumably, consistent serialization.

Coherence partitioned caches store keys and values in serialized form, so they compute the hash function on the serialized version of the key, and do equality checks on the serialized keys. Even though the serialized stream is equivalent for the purposes of reconstructing the object, it is not guaranteed identical as needed for the hashing and equality checking operations.

To complicate matters more, in near-cache, the object is kept in deserialized form and hence its equals() and hashCode() methods are used instead.

Finally, Coherence recommends the use of their proprietary POF serialization, which usually results in reduced serialized size and gives direct control of serialization to the object being serialized.