Read Cache Data from File system or diskpath

问题:

If overflowToDisk is enabled and Disk path is configured, then if data is not found in the memory should it automatically search from diskpath?

Refer the configuration mentioned

When overFlowToDisk gets activated in EHCACHE?

My case

1) Cache warm up from DB before application start

2) Load data from DB with loader implementation

3) Initially DB has 2000 data. So we have 1000 in memory (ABC_007) rest 1000 we have in the DISK.

Is this correct?

 <cache name="ABC_007"
           maxElementsInMemory="1000"
           maxElementsOnDisk="10000"
           overflowToDisk="true"
           timeToIdleSeconds="..."
           timeToLiveSeconds="...">
    </cache>

If I search for data which is not in ABC_007, it will be retrieved from DISKPATH. Am I right on this one?

Now, if I implement Cache read through functionality that is if the data is not available in Cache (including diskpath), I should search in the DB.

Now I find the Data. Does it repopulate the Cache?

If ABC_007 still consists 1000 elements. Where it will be stored? ABC_007 or disk?

Please Correct my understandings.

For example refer the sample code

Cache cache = manager.getCache("ABC_007");

Element element = null;

String key = null;

for (int i=0 ; i<2000 ; i++) {

key =  "keyInCache" + i ;

element = new Element (key , "value1");
cache.put(element);

}

Now when i cross 1000 then as per configuration , 1001 to 2000 elements will be stored in disk .

 <cache name="ABC_007"
           maxElementsInMemory="1000"
           maxElementsOnDisk="10000"
           overflowToDisk="true"
           timeToIdleSeconds="..."
           timeToLiveSeconds="...">

AM I RIGHT ?

Now I want the Value for the

Key = keyInCache1700

element = cache.get(key);

FROM Where I will get the Value ?

My understanding - as ABC_007 cache has maxElementsInMemory="1000" , that means it can srore upto 1000 key value in memory and value for the key keyInCache1700 will be retrieved from the Disk ...

AM I Correct ?

回答1:

The answer depends on your version of Ehcache.

As of Ehcache 2.6, the storage model is no longer an overflow one but a tiered one. In the tiered storage model, all data will always be present in the lowest tier. Items will be present in the higher tiers based on their hotness.

Possible tiers for open source Ehcache are:

• On-heap that is on the JVM heap
• On-disk which is the lowest one

By definition high tiers have lower latency but less capacity than lower tiers.

So for a cache configured with overflowToDisk, all the data will always be inside the disk tier. It will store the key in memory and the data on disk.

When looking for an entry inside the cache, the tiers are considered from highest to lowest. In your example, the data will be retrieved as follows:

1. Search in memory
   • If found, return it
2. Search on disk
   • If found, add to memory tier (hot data) and return it. This can cause another entry to be evicted from memory
3. Use your cache loader to retrieve it from DB
   • When found, add it to the cache and return it

回答2:

I'm just going to outline/ summarize my rough idea of how EHCache works:

1. It's essentially a HashMap.
2. It keeps the HashMap of keys in memory, at all times.
3. The actual content of items can be stored either in memory, or (when there are enough items) overflow to disk.

Conclusion: My understanding is that EHCache knows what keys it has cached, and where the items are currently stored. This is a basic necessity for a cache to retrieve items quickly.

If an item is unknown to EHCache, I wouldn't expect it to go looking on disk for it.

You should definitely implement "read-thru to DB" logic, around your use of the cache. Items not found in the cache must obviously be read from the DB. Adding them to cache at that time would be expected to put them in memory, as they're currently hot (recently used).