Come distinguere tra tempo di vita e tempo di inattività in ehcache

103

La documentazione su Ehache dice:

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.

Capisco timeToIdleSeconds

Ma significa che dopo la creazione e il primo accesso di un elemento della cache, timeToLiveSeconds non è più applicabile?

java ehcache

— Jacques René Mesrine
fonte

Risposte:

156

timeToIdleSecondsconsente di conservare l'oggetto memorizzato nella cache fintanto che viene richiesto in periodi inferiori a timeToIdleSeconds. timeToLiveSecondsfarà sì che l'oggetto memorizzato nella cache venga invalidato dopo quel numero di secondi indipendentemente da quante volte o quando è stato richiesto.

Diciamolo timeToIdleSeconds = 3. Quindi l'oggetto verrà invalidato se non è stato richiesto per 4 secondi.

In timeToLiveSeconds = 90tal caso l'oggetto verrà rimosso dalla cache dopo 90 secondi, anche se è stato richiesto pochi millisecondi nel 90 ° secondo della sua breve vita.

— Boris Pavlović
fonte

Quindi presumo che vogliamo sempre impostare il tempo di inattività <ttl

— Jacques René Mesrine

Nel commento sopra quando dici che "Diciamo che timeToIdleSeconds = 3. L'oggetto sarà invalidato se non è stato richiesto per 4 secondi.", Quando dici invalidare - cosa significa? Lo rimuove dall'heap? Se l'oggetto viene rimosso dalla cache, allora sono confuso su quale sia l'uso del parametro timeToLive. Quando abbiamo eseguito il POC, stiamo vedendo che i dati vengono recuperati dalla fonte dopo timeetoIdleseconds. Sebbene timetoLive sia un valore molto più alto, mi sarei aspettato che venisse recuperato dalla cache poiché timetoLive ha un valore molto più alto di timeToIdle nel nostro caso.

— Gayathri

@Gayathri Se hai un elemento di dati a cui si accede spesso (ogni due secondi) ma ha un TTL di sessanta secondi. Sarebbe comunque estratto dalla sorgente una volta ogni sessanta secondi anche se vi si accede continuamente (mai inattivo).

— C. Ross

Come seguito al primo commento (di @ JacquesRenéMesrine). Per il caso sia TTL che TTI sono impostati (cioè maggiore di zero): 1) TTI> = TTL: TTI non ha effetto . L'iscrizione è considerata scaduta dopo creationTime + TTL2) TTI <TTL: L'iscrizione è considerata scaduta dopomin((max(lastAccessTime, creationTime) + TTI), (creationTime + TTL))

— Timur Milovanov

"indipendentemente" -> "indipendentemente"

— Magnus

Se imposti entrambi, expirationTimesarà Math.min(ttlExpiry, ttiExpiry), dove

ttlExpiry = creationTime + timeToLive
ttiExpiry = mostRecentTime + timeToIdle

Il codice sorgente completo qui .

— Lee Chee Kiam
fonte

Ora il comportamento ha senso per me. Grazie per averlo sottolineato, soprattutto per la Math.minparte.

— Prakash K

Questo codice lo rende più chiaro della spiegazione umana sopra :-)

— Maga Abdurakhmanov

Dalla vecchia documentazione 1.1 (disponibile in Google Cache, che è più facile da sfogliare e più informativa rispetto ai documenti attuali AFAIK):

timeToIdleSeconds

Questo è un attributo opzionale.

I valori legali sono numeri interi compresi tra 0 e Integer.MAX_VALUE.

È il numero di secondi che un Elemento dovrebbe vivere dall'ultimo utilizzo. Usato significa inserito o acceduto.

0 ha un significato speciale, che non è controllare l'elemento per il tempo di inattività, ovvero resterà inattivo per sempre.

Il valore predefinito è 0.

timeToLiveSeconds

Questo è un attributo opzionale.

I valori legali sono numeri interi compresi tra 0 e Integer.MAX_VALUE.

È il numero di secondi che un Elemento dovrebbe vivere da quando è stato creato. Creato significa inserito in una cache utilizzando il metodo Cache.put.

0 ha un significato speciale, che non è controllare l'elemento per il tempo di vivere, cioè vivrà per sempre.

Il valore predefinito è 0.

— Damo
fonte