Cómo diferenciar entre tiempo de vida y tiempo de inactividad en ehcache

103

Los documentos sobre ehache dicen:

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.

Entiendo timeToIdleSeconds

Pero, ¿significa que después de la creación y el primer acceso de un elemento de caché, timeToLiveSeconds ya no es aplicable?

java ehcache

— Jacques René Mesrine
fuente

Respuestas:

156

timeToIdleSecondspermite que el objeto en caché se mantenga siempre que se solicite en períodos inferiores a timeToIdleSeconds. timeToLiveSecondshará que el objeto en caché se invalide después de esa cantidad de segundos, independientemente de cuántas veces o cuándo se solicitó.

Digamos eso timeToIdleSeconds = 3. Entonces, el objeto se invalidará si no se ha solicitado durante 4 segundos.

Si timeToLiveSeconds = 90, el objeto se eliminará de la caché después de 90 segundos, incluso si se ha solicitado unos pocos milisegundos en el segundo 90 de su corta vida.

— Boris Pavlović
fuente

Así que supongo que siempre queremos establecer el tiempo de inactividad <ttl

— Jacques René Mesrine

En el comentario anterior, cuando dice que "Digamos que timeToIdleSeconds = 3. El objeto se invalidará si no se ha solicitado durante 4 segundos", cuando dice invalidar, ¿qué significa? ¿Lo quita del montón? Si el objeto se elimina de la memoria caché, entonces estoy confundido sobre cuál es el uso del parámetro timeToLive. Cuando hicimos el POC, vemos que los datos se obtienen de la fuente después de un tiempo de Idlesegundos. Aunque timetoLive es un valor mucho más alto, habría esperado que se recuperara de la caché ya que timetoLive tiene un valor mucho más alto que timeToIdle en nuestro caso.

— Gayathri

@Gayathri Si tiene un elemento de datos al que se accede con frecuencia (cada dos segundos) pero tiene un TTL de sesenta segundos. Todavía se extraerá de la fuente una vez cada sesenta segundos, incluso si se accede a él continuamente (nunca inactivo).

— C. Ross

Como seguimiento al primer comentario (por @ JacquesRenéMesrine). Para el caso de TTL y TTI establecidos (es decir, mayor que cero): 1) TTI> = TTL: TTI no tiene ningún efecto . La entrada se considera vencida después de creationTime + TTL2) TTI <TTL: La entrada se considera vencida después demin((max(lastAccessTime, creationTime) + TTI), (creationTime + TTL))

— Timur Milovanov

"independientemente" -> "independientemente"

— Magnus

Si establece ambos, el expirationTimeserá Math.min(ttlExpiry, ttiExpiry), donde

ttlExpiry = creationTime + timeToLive
ttiExpiry = mostRecentTime + timeToIdle

Código fuente completo aquí .

— Lee Chee Kiam
fuente

Ahora el comportamiento tiene sentido para mí. Gracias por señalar esto, especialmente la Math.minparte.

— Prakash K

Este código lo hace más claro que la explicación humana anterior :-)

— Maga Abdurakhmanov

De la antigua documentación 1.1 (disponible en Google Cache, que es más fácil de navegar y más informativa que los documentos actuales AFAIK):

timeToIdleSeconds

Este es un atributo opcional.

Los valores legales son números enteros entre 0 y Integer.MAX_VALUE.

Es la cantidad de segundos que debe vivir un elemento desde que se usó por última vez. Usado significa insertado o accedido.

0 tiene un significado especial, que no es para comprobar si el elemento está inactivo, es decir, permanecerá inactivo para siempre.

El valor predeterminado es 0.

timeToLiveSeconds

Este es un atributo opcional.

Los valores legales son números enteros entre 0 y Integer.MAX_VALUE.

Es la cantidad de segundos que debe vivir un elemento desde que fue creado. Creado significa insertado en una caché utilizando el método Cache.put.

0 tiene un significado especial, que no es para comprobar si el Elemento tiene tiempo de vida, es decir, vivirá para siempre.

El valor predeterminado es 0.

— Damo
fuente