Comprende el código bien previamente a usarlo a tu proyecto si ttienes algo que aportar puedes comentarlo.
Solución:
Spring @Cacheable no tiene ninguna opción configurable para establecer TTL para el caché, aunque puede construirlo usando @CacheEvict y @Scheduled, de la siguiente manera:
@CacheEvict(allEntries = true, cacheNames = "cache_1", "cache_2" )
@Scheduled(fixedDelay = 30000)
public void cacheEvict()
Puede encontrar una solución/explicación detallada aquí – Configuración de TTL para @Cacheable – Spring.
Con Spring Boot, pude lograr el éxito con esto:
Primero, necesitas agregar spring-boot-starter-data-redis artefacto a su archivo POM.
org.springframework.boot
spring-boot-starter-data-redis
Después de esto, debe agregar las siguientes configuraciones requeridas en sus archivos application.properties:
#------ Redis Properties -------------
spring.cache.type=redis
spring.redis.host=127.0.0.1
spring.redis.port=6379
spring.cache.redis.time-to-live=600000
La propiedad a establecer es spring.cache.redis.time-to-live (El valor está en milisegundos. En este caso, se establecieron 10 minutos). Con este, @Cacheable funciona con el TTL predeterminado establecido.
Primavera es bastante claro acerca de las políticas de TTL/TTI (vencimiento) y de desalojo como se explica en el núcleo Guía de referencia de Spring Framework aquí. En otras palabras, los “predeterminados” dependen completamente del almacén de datos subyacente (también conocido como proveedor de almacenamiento en caché) utilizado con el Bota de primavera aplicación a través de la Abstracción de caché de primavera.
Mientras de Arpit La solución es una buena solución y una solución genérica y transferible entre diferentes proveedores de almacenamiento en caché (almacenes de datos), tampoco puede cubrir políticas de caducidad/desalojo más específicas, como el tipo de acción a realizar cuando se produce una caducidad/desalojo, digamos OVERFLOW_TO_DISK o LOCAL_DESTROY solo (como en un escenario distribuido de alta disponibilidad (quizás basado en zonas), o INVALIDAR, etc.
Por lo general, dependiendo de la UC, desalojar “todas” las entradas no es una opción aceptable y es una de las razones por las que Primavera delega esta responsabilidad al proveedor de almacenamiento en caché ya que esta capacidad varía mucho entre un proveedor y otro.
En resumen… definitivamente revise los requisitos para su UC y combine el proveedor de almacenamiento en caché apropiado con las capacidades que coincidan con su UC. Primavera admite una amplia variedad de proveedores de almacenamiento en caché, desde Redis hasta Apache Geode/Pivotal GemFire y avellana, etc, cada uno con capacidades diferentes/similares en este sentido.