Como diferenciar entre tempo de vida e tempo de inatividade no ehcache

103

A documentação sobre ehache diz:

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.

Eu entendo timeToIdleSeconds

Mas isso significa que após a criação e primeiro acesso de um item de cache, o timeToLiveSeconds não é mais aplicável?

java ehcache

— Jacques René Mesrine
fonte

Respostas:

156

timeToIdleSecondspermite que o objeto armazenado em cache seja mantido enquanto for solicitado em períodos menores que timeToIdleSeconds. timeToLiveSecondsfará com que o objeto em cache seja invalidado depois de tantos segundos, independentemente de quantas vezes ou quando ele foi solicitado.

Vamos dizer isso timeToIdleSeconds = 3. Então o objeto será invalidado se não for solicitado por 4 segundos.

Se timeToLiveSeconds = 90, então o objeto será removido do cache após 90 segundos, mesmo que tenha sido solicitado alguns milissegundos no 90º segundo de sua curta vida.

— Boris Pavlović
fonte

Então, presumo que sempre queremos definir o tempo de idletismo <ttl

— Jacques René Mesrine

No comentário acima, quando você diz que "Digamos que timeToIdleSeconds = 3. O objeto será invalidado se não for solicitado por 4 segundos.", Quando você disser invalidate - o que significa? Isso o remove da pilha? Se o objeto for removido do cache, fico confuso sobre como usar o parâmetro timeToLive. Quando fizemos o POC, vemos que os dados são buscados na fonte após timetoIdleseconds. Embora o timetoLive seja um valor muito mais alto, eu esperava que ele fosse obtido do cache, já que o timetoLive tem um valor muito mais alto do que timeToIdle em nosso caso.

— Gayathri

@Gayathri Se você tiver um item de dados que é acessado com frequência (a cada dois segundos), mas tem um TTL de sessenta segundos. Ele ainda seria retirado da origem uma vez a cada sessenta segundos, mesmo se fosse acessado continuamente (nunca ocioso).

— C. Ross

Como seguimento do primeiro comentário (por @ JacquesRenéMesrine). Para o caso de TTL e TTI definidos (ou seja, maior que zero): 1) TTI> = TTL: TTI não tem efeito . A entrada é considerada expirada após creationTime + TTL2) TTI <TTL: A entrada é considerada expirada apósmin((max(lastAccessTime, creationTime) + TTI), (creationTime + TTL))

— Timur Milovanov

"irregardless" -> "independentemente"

— Magnus de

Se você definir ambos, o expirationTimeserá Math.min(ttlExpiry, ttiExpiry), onde

ttlExpiry = creationTime + timeToLive
ttiExpiry = mostRecentTime + timeToIdle

Código-fonte completo aqui .

— Lee Chee Kiam
fonte

Agora, o comportamento faz sentido para mim. Obrigado por apontar isso, especialmente a Math.minparte.

— Prakash K

Este código torna-o mais claro do que a explicação humana acima :-)

— Maga Abdurakhmanov

A partir da antiga documentação 1.1 (disponível no Google Cache, que é mais fácil de navegar e mais informativo do que os documentos atuais AFAIK):

timeToIdleSeconds

Este é um atributo opcional.

Os valores legais são inteiros entre 0 e Integer.MAX_VALUE.

É o número de segundos que um Elemento deve viver desde que foi usado pela última vez. Usado significa inserido ou acessado.

0 tem um significado especial, que não é verificar o tempo de inatividade do Elemento, ou seja, ele ficará inativo para sempre.

O valor padrão é 0.

timeToLiveSeconds

Este é um atributo opcional.

Os valores legais são inteiros entre 0 e Integer.MAX_VALUE.

É o número de segundos que um Elemento deve viver desde que foi criado. Criado significa inserido em um cache usando o método Cache.put.

0 tem um significado especial, que não é verificar o elemento para viver, ou seja, ele viverá para sempre.

O valor padrão é 0.

— Damo
fonte