ehcache

More DiskStore optimizations (item 6)

It occurred to me that a disk-cache doesn't have to be as rigorous as an in-mem cache, and thus we can allow slightly random expirations at the expensive of memory space. Namely work like a CPU cache which expires elements on collisions.


Namely you have key.hashCode().. You also have whether the key can serialize or not. If not, you have to keep the key in memory as currently happens.. Otherwise, store the int hashcode in a map, then null out the key.

When you serialize, you serialize BOTH the key and the value.

So now you have
Map<Integer,DiskRecord> hashKey2DiskRecord;

so now your diskCache can safely prove that nothing matches on disk.. Or, on a match, you go load load the ObjectInputStream.. read the first object.. do loadedObj.equals(searchKey), and load the 'value' portion up if matched.

There isn't much value if the serialized object is small.. Thus on passivation, you do the object-serialization:
if (exception) keep key in mem
if (buffSize < MIN_DISK_KEY_SIZE) keep key in mem

Your diskelement then contains at least the following fields:

class DiskElement {
long diskOffset
int diskSpace
Object key;
boolean key_passivated;
...


Obviously it becomes VERY expensive to 'walk' the hash-linked-list, as you'd have to disk-fetch and deserialize every key on every search. Thus you trigger an EVICT if putting over an existing item, or have subsequent overlapping hash-items keep their key in memory. Since the probability of collisions is low, this should still mean most elements get to put their key on disk.

Again this is targeting large-key objects (such as hibernate CacheKey or QueryCacheKey)

Now with persistent enabled, keys would already have to be valid to serialize, but due to legacy code, those that use diskStorage but not persistence would previously never have seen an inconsistent load error (if the key had transient fields for example that didn't properly re-initialize).. So I think this model needs to be off by default. in other words, I think this CAN break existing code, so err on safety by default.

You can add a persistentKeys=true option to the ehcache-failsafe.xml Which is disabled by default (unless persistent=true). Thus people have to enable this capability.

In the code all it means is that we don't even try to passivate the keys, and thus the DiskStore.key_passivated is always false. It also means that we are more eagerly evicting hash-collided disk elements, which personally I think is acceptable. If there would have been thrashing, it would resolve itself in the in-mem cache.