Présentation Terracotta

J’ai eu le plaisir d’assister à une présentation de Terracota par son créateur Ari Zilka, organisée par la société Zenika, que je salue au passage pour son approche novatrice et cette initiative réussie.
Terracota est un cluster de JVM, il permet de synchroniser des JVM entre elles en se basant sur le principe du NAS mais au niveau de la mémoire : NAM pour Network Attached Memory. […]

J’ai eu le plaisir d’assister à une présentation de Terracota par son créateur Ari Zilka, organisée par la société Zenika, que je salue au passage pour son approche novatrice et cette initiative réussie.
Terracota est un cluster de JVM, il permet de synchroniser des JVM entre elles en se basant sur le principe du NAS mais au niveau de la mémoire : NAM pour Network Attached Memory. Oubliez la serialisation de session, fini le stockage en base d’état d’un objet, Terracotta permet de se concentrer sur l’essentiel et de réduire les dépendances avec la base de données. L’exemple présenté montrait comment mieux gérer le principe d’enregistrement sur un site avec email de confirmation. La technique classique consiste à stocker en base une donnée d’identification avec un statut, ce statut changeant dès lors que l’email est reçu. Avec Terracotta cette donnée reste en mémoire et est partagée par tous les serveurs, elle n’est stockée en base qu’à réception de l’email. De plus Terracotta stocke sur disque l’état de la mémoire et permet ainsi de gérer le crash d’un serveur.
Pour ma part, bien que je me sois intéressé à cet outil depuis sa création et l’ai évoqué sur ce blog lors de son passage en open source, je ne l’ai pas encore mis en oeuvre. Pourtant travaillant sur WebObjects l’avantage est évident, en effet Apple avait pensé la solution de déploiement de son framework avec une JVM lancée par instance d’application WebObjects. Le tout géré par un simple et très pratique outil : le Monitor. L’Apple Store est d’ailleurs toujours déployé avec ce principe. Cette approche vient surtout du fait que EOF (ORM issu de NeXT) a un seul défaut : il ne gère pas le multithread. Ainsi pour que les différentes instances de l’application connaissent chacune l’état de l’autre au niveau des objets métiers qu’elles utilisent en commun, chaque accès base (modification, création, suppression) est enregistré dans une table qui est lu par les autres instances qui rafraichissent alors leurs objets. Avec Terracotta il suffit simplement d’implémenter le concept de DSO (Distributed Shared Objects) sur le graphe d’objet à partager et le tour est joué. Pour aller encore plus loin et être plus générique il faudrait implémenter Terracotta au niveau du cache EOF comme cela a été fait avec EHCache and Hibernate. Bref il est temps que je m’y penche sérieusement, ceci fera d’ailleurs l’objet d’un prochain billet avec un bon exemple de mise en oeuvre de Terracotta.

A noter que cette présentation est la première d’une (j’espère) longue série pour Zenika, alors merci encore et vivement la prochaine…