Home/ Questions/Q 8999607
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-16T00:12:09+00:00

I am planning on using a SelfPopulatingCache in my application component, as it supports

  • 0

I am planning on using a SelfPopulatingCache in my application component, as it supports read-through and what seems like a backing cache for refreshes.

However, I am a little bemused by the timeToLiveSeconds configuration. This is my test configuration:

<ehcache>
    <diskStore path="java.io.tmpdir"/>

    <cache name="myCache" maxElementsInMemory="50000" overflowToDisk="false"
    eternal="false" timeToIdleSeconds="0" timeToLiveSeconds="2"/>

</ehcache>

In my unit tests, I perform the following:

  • Verify there are 2 entries in my cache
  • Sleep for 3 seconds
  • However, after the sleep there are still 2 entries in my cache.

Per other posts online (and not the documentation), when I next perform a read, my entries should be evicted.

However, instead the CacheEntryFactory will be invoked, and a null Element will be added to the cache for my expired elements.

Is there any way to configure this to instead perform a full eviction when timeToLiveSeconds expires?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I believe “full eviction” can only happen if there was a separate expiry thread. Unfortunately, for in-memory entries there’s no such thing. Quoting Ehcache FAQ:

    Because the MemoryStore has a fixed maximum number of elements, it
    will have a maximum memory use equal to the number of elements
    multiplied by the average size. When an element is added beyond the
    maximum size, the LRU element gets pushed into the DiskStore. While we
    could have an expiry thread to expire elements periodically, it is far
    more efficient to only check when we need to. The tradeoff is higher
    average memory use. The expiry thread keeps the DiskStore clean. There
    is hopefully less contention for the DiskStore’s locks because
    commonly used values are in the MemoryStore. We mount our DiskStore on
    Linux using RAMFS so it is using OS memory. While we have more of this
    than the 2GB 32-bit process size limit, it is still an expensive
    resource. The DiskStore thread keeps it under control. If you are
    concerned about CPU utilization and locking in the DiskStore, you can
    set the diskExpiryThreadIntervalSeconds to a high number, such as 1
    day. Or, you can effectively turn it off by setting the
    diskExpiryThreadIntervalSeconds to a very large value.

    • 0