Introduction

Pour ceux qui ne connaissent pas les détails du problème, revenons sur certaines informations de base pour comprendre la problématique à laquelle font face ces utilisateurs. Lorsque, par exemple, est affiché un objet, disons en mode vue full, eZ Publish stocke le résultat HTML du traitement du template (il le met en cache). Cet élément mis en cache est appelé Cache de vue et sera réutilisé la prochaine fois que ce contenu sera affiché par le même moyen. Cette technique évite de réaliser le traitement des templates d'affichage chaque fois qu'un objet de contenu est affiché, allégeant significativement la charge de l'application. Ce système existe maintenant depuis longtemps (un peu avant la version 3.0 de eZ Publish).

Pour que le contenu affiché soit pleinement synchronisé avec le vrai contenu, c'est à dire synchronisé en temps réel autant que possible, le cache de vue d'un objet de contenu expire chaque fois qu'une nouvelle version de l'objet est publiée. Cela signifie que le code HTML caché doit être régénéré, impliquant que le template d'affichage soit à nouveau traité lorsque la nouvelle version de l'objet de contenu est affichée pour la première fois. Vous trouverez plus d'informations dans dans la documentation en ligne : http://ez.no/doc/ez_publish/technical_manual/4_0/features/view_caching.

Le cache de vue est pris en exemple ici, mais les améliorations apportées par la fonctionnalité Stale Cache s'appliquent également aux caches de blocs et à tout autre type de cache. Retenez également que cette fonctionnalité s'applique tant aux environnements clusterisés qu'à ceux qui ne le sont pas.

Lorsque plusieurs utilisateurs demandent le même objet dont le cache de vue vient d'expirer, leurs requêtes sont placées en file d'attente, la première d'entre elles étant la seule à déclencher la régénération du cache de vue. Cela implique que presque toutes les requêtes (exceptée la première) reçues à ce moment précis devront attendre que la nouvelle version cachée soit disponible, entraînant deux inconvénients majeurs:

• Expérience utilisateur: les clients attendent au moins le temps nécessaire à la régénération du cache, ce qui peut être long lorsque des templates complexes sont utilisés.
• Au niveau du système: toutes ces requêtes en attente mettent la pression sur les ressources du système (situations de compétition, interblocages (deadlocks), etc...).