116

The docs on ehache says:

timeToIdleSeconds: Sets the time to idle for an element before it expires.
i.e. The maximum amount of time between accesses before an element expires

timeToLiveSeconds: Sets the time to live for an element before it expires.
i.e. The maximum time between creation time and when an element expires.

I understand timeToIdleSeconds

But does it means that after the creation & first access of a cache item, the timeToLiveSeconds is not applicable anymore ?

Pascal Thivent
  • 562,542
  • 136
  • 1,062
  • 1,124
Jacques René Mesrine
  • 46,127
  • 27
  • 66
  • 104

3 Answers3

178

timeToIdleSeconds enables cached object to be kept in as long as it is requested in periods shorter than timeToIdleSeconds. timeToLiveSeconds will make the cached object be invalidated after that many seconds regardless of how many times or when it was requested.

Let's say that timeToIdleSeconds = 3. Then the object will be invalidated if it hasn't been requested for 4 seconds.

If timeToLiveSeconds = 90, then the object will be removed from cache after 90 seconds, even if it has been requested few milliseconds in the 90th second of its short life.

Mikko Östlund
  • 2,635
  • 3
  • 17
  • 14
Boris Pavlović
  • 63,078
  • 28
  • 122
  • 148
  • 6
    So I presume we always want to set idletime < ttl – Jacques René Mesrine Apr 21 '10 at 03:41
  • In the comment above when you say that "Let's say that timeToIdleSeconds = 3. Object will be invalidated if it hasn't been requested for 4 seconds.", when you say invalidate - what does it mean? Does it remove it from heap? If the object is removed from cache, then I am confused about what is the use of timeToLive parameter at all. When we did the POC, we are seeing that data is fetched from source after timetoIdleseconds. Although the timetoLive is a much higher value, I would have expected that it is fetched from cache since the timetoLive is much higher value than timeToIdle in our case. – Gayathri Jan 30 '11 at 16:45
  • 4
    @Gayathri If you had a data item that is accessed often (every two seconds) but has a TTL of sixty seconds. It would still be pulled from source once every sixty seconds even if it is accessed continually (never idle). – C. Ross Mar 01 '13 at 14:38
  • 10
    As follow-up to first comment (by @JacquesRenéMesrine). For the case both TTL & TTI set (i.e. greater than zero): 1) TTI >= TTL: TTI has *no effect*. Entry is considered _expired_ after `creationTime + TTL` 2) TTI < TTL: Entry is considered _expired_ after `min((max(lastAccessTime, creationTime) + TTI), (creationTime + TTL))` – Timur Milovanov Dec 09 '15 at 15:44
  • "irregardless" -> "regardless" – Magnus Sep 18 '17 at 16:50
47

If you set both, the expirationTime will be Math.min(ttlExpiry, ttiExpiry), where 

ttlExpiry = creationTime + timeToLive
ttiExpiry = mostRecentTime + timeToIdle

Full source code here.

Lee Chee Kiam
  • 11,450
  • 10
  • 65
  • 87
22

From the old 1.1 documentation (available in Google Cache, which is easier to browse and more informative than the current docs AFAIK):

timeToIdleSeconds

This is an optional attribute.

Legal values are integers between 0 and Integer.MAX_VALUE.

It is the number of seconds that an Element should live since it was last used. Used means inserted or accessed.

0 has a special meaning, which is not to check the Element for time to idle, i.e. it will idle forever.

The default value is 0.

timeToLiveSeconds

This is an optional attribute.

Legal values are integers between 0 and Integer.MAX_VALUE.

It is the number of seconds that an Element should live since it was created. Created means inserted into a cache using the Cache.put method.

0 has a special meaning, which is not to check the Element for time to live, i.e. it will live forever.

The default value is 0.

Damo
  • 11,410
  • 5
  • 57
  • 74