Cache Off vs Cache On: Choosing Thymeleaf Template Reload Strategy

Goal

Determine the optimal configuration for spring.thymeleaf.cache that balances rapid template iteration during local development with deterministic, performant rendering in production, especially in containerized or clustered deployments.

Constraints & Uncertainty

When spring.thymeleaf.cache is set to false, Thymeleaf checks the file system’s last‑modified timestamp on every render, enabling instant visual feedback without application restarts. In production, setting the flag to true loads each template once, parses it into an internal DOM, and reuses that representation, eliminating I/O overhead. However, many deployment pipelines mount templates from read‑only volumes or symlinked directories where timestamps do not update reliably; this can cause the cached template to serve stale content even after a new build is deployed. A documented alternative is to explicitly clear the resolver cache (e.g., via a ContextRefreshedEvent listener or Spring Boot DevTools), but this adds operational complexity and a potential race window during releases.

Questions

• In a Docker‑based deployment, does disabling spring.thymeleaf.cache reliably prevent stale template rendering, or should we rely on explicit cache invalidation?
• What are the performance trade‑offs of keeping the cache enabled in production versus clearing it on each deployment?
• How can we ensure that timestamp‑based invalidation works consistently across clustered instances without manual intervention?