OSCache est une solution de cache opensource Java qui se présente sous trois formes :
filtre de servlet, taglib JSP et API.
Nous avons employé cette solution dans le cadre de la refonte d’un site Internet à grande fréquentation. Voici, en quelques points pratiques, ce qui distingue OSCache des autres solutions opensource.
Composants “clé en main”
L’utilisation d’un filtre pour cacher des pages entières d’un site peut apporter un gain en performances important, Celui-ci intercepte les requêtes avant qu’elles n’atteignent les composants de l’application. OSCache propose un tel composant et nous affranchi ainsi de son implémentation. Malheureusement, cette approche est rarement applicable à toutes les URLs d’un site. Aussi, pour une gestion fine des urls à filtrer et considérant le manque de flexibilité des mappings de la specification Servlet, il est pratique d’étendre le filtre OSCache.
On remarque par ailleurs que le filtre OSCache supporte les données “gzippées”. En cachant directement les réponses compressées, on réduit donc l’utilisation de la memoire par OSCache.
La solution à base de taglib JSP d’OSCache apporte plus de flexibilité que la précédente, dans la mesure où l’on peut sélectionner des fragments de JSP à cacher. Cependant, elle n’est pas adaptée au modèle MVC, dans lequel les données sont généralement collectées avant le traitement de la vue. (On peut toujours partir sur une intégration spécifique d’OSCache via l’API).
Gestion des accès concurrents
Lors d’accès concurrents, on peut choisir entre un mode de reconstruction du cache bloquant ou non-bloquant. Dans ce dernier cas, un thread se charge de reconstruire le cache pendant que les autres se voient servir le contenu expiré. Ceci peut améliorer de façon importante la disponibilité de l’application.
OSCache peut optionnellement persister les données sur disque. Ceci aussi améliore la disponibilité du site lors d’un redémarrage du serveur.
Reprise sur erreur
L’un des intérêts d’OSCache est sa capacité à restituer du contenu expiré en cas d’erreur de rafraichissement des données. Le site reste donc en partie naviguable. A noter que ceci n’est pas implémenté par défaut dans le filtre OSCache, raison supplémentaire pour l’étendre.
En conclusion, cette solution de cache, finement paramètrable, se revèle adaptée aux problèmatiques de disponibilité d’applications web Java. Comme nous l’avons évoqué, dans le cas d’une implémentation spécifique d’un cache d’objets, il est nécessaire de passer par l’API OSCache. Aussi, nous montrerons dans un prochain article comment intégrer un tel cache sans modifier la couche métier, en utilisant les concepts de l’AOP.
