Как отличить время жизни от времени бездействия в ehcache

103

Документы на ehache говорят:

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.

Я понимаю timeToIdleSeconds

Но означает ли это, что после создания и первого доступа к элементу кеша timeToLiveSeconds больше не применяется?

java ehcache Жак Рене Мезрин
источник

Ответы:

156

timeToIdleSecondsпозволяет хранить кэшированный объект до тех пор, пока он запрашивается в периоды короче, чем timeToIdleSeconds. timeToLiveSecondsсделает кешированный объект недействительным после этого количества секунд, независимо от того, сколько раз и когда он был запрошен.

Скажем так timeToIdleSeconds = 3. Тогда объект будет признан недействительным, если он не запрашивался в течение 4 секунд.

Если timeToLiveSeconds = 90, то объект будет удален из кеша через 90 секунд, даже если он был запрошен несколько миллисекунд на 90-й секунде его короткого срока службы.

Борис Павлович
источник
1
Поэтому я предполагаю, что мы всегда хотим установить время простоя <ttl
Жак Рене Мезрин
В комментарии выше, когда вы говорите, что «Допустим, timeToIdleSeconds = 3. Объект будет признан недействительным, если он не запрашивался в течение 4 секунд.», Когда вы говорите «недействительный» - что это значит? Удаляет ли это из кучи? Если объект удаляется из кеша, я не понимаю, зачем вообще нужен параметр timeToLive. Когда мы выполняли POC, мы видим, что данные извлекаются из источника через timetoIdleseconds. Хотя timetoLive имеет гораздо более высокое значение, я ожидал, что оно извлекается из кеша, поскольку в нашем случае timetoLive имеет гораздо большее значение, чем timeToIdle.
Гаятри
3
@Gayathri Если бы у вас был элемент данных, к которому часто обращаются (каждые две секунды), но имеет TTL шестьдесят секунд. Он все равно будет извлекаться из источника каждые шестьдесят секунд, даже если к нему обращаются постоянно (никогда не простаивает).
К. Росс
8
В продолжение первого комментария (от @ JacquesRenéMesrine). Для случая оба TTL и TTI установлены (то есть больше нуля): 1) TTI> = TTL: TTI не имеет никакого эффекта . Запись считается истекшей после creationTime + TTL2) TTI <TTL: Запись считается истекшей послеmin((max(lastAccessTime, creationTime) + TTI), (creationTime + TTL))
Тимур Милованов
«безотносительно» -> «независимо»
Магнус
41

Если вы установите оба, то expirationTimeбудет Math.min(ttlExpiry, ttiExpiry), где

ttlExpiry = creationTime + timeToLive
ttiExpiry = mostRecentTime + timeToIdle

Полный исходный код здесь .

Ли Чи Киам
источник
1
Теперь такое поведение имеет для меня смысл. Спасибо, что указали на это, особенно на ту Math.minчасть.
Prakash K
Этот код делает его более понятным, чем человеческое объяснение выше :-)
Мага Абдурахманов
22

Из старой документации 1.1 (доступной в Google Cache, который легче просматривать и более информативен, чем текущие документы AFAIK):

timeToIdleSeconds

Это необязательный атрибут.

Допустимые значения - это целые числа от 0 до Integer.MAX_VALUE.

Это количество секунд, в течение которых элемент должен жить с момента последнего использования. Используемый означает вставленный или доступный.

0 имеет особое значение, которое не проверяет элемент на время бездействия, т.е. он будет бездействовать вечно.

Значение по умолчанию - 0.

timeToLiveSeconds

Это необязательный атрибут.

Допустимые значения - это целые числа от 0 до Integer.MAX_VALUE.

Это количество секунд, в течение которых элемент должен жить с момента его создания. Создано - значит вставлено в кеш с помощью метода Cache.put.

0 имеет особое значение, которое заключается не в проверке элемента на время жизни, т.е. он будет жить вечно.

Значение по умолчанию - 0.

Дамо
источник