Ari Zilka, de Terracotta, a choisi d'insister sur le fait qu'une application utilisant les mécanismes de Network Attach Memory engendre les mêmes difficultés qu'une application à développer en multi-threadé. Pour cela, il s'est servi du plugin eclipse de visualisation de comportement d'un cluster Terracotta, qui permet de facilement identifier les baisses de capacité de traitement associées à l'apparition de plusieurs JVM attaquant le même contenu mémoire. Très visuel, et qui a le mérite de nous forcer à repenser la structure de nos traitements.
La session suivante a vu un présentateur Sun et un présentateur Oracle parler d'un projet... Eclipse : la nouvelle version de l'implémentation JPA TopLink, à savoir EclipseLink. Cette version sera complète et open source, en contenant tout ce qu'il y avait dans Toplink et pas seulement la partie JPA. Elle sera embarquée dans le serveur d'application Glassfish V3. Après un rappel des principes de JPA, on a passé en revue un certain nombre de spécificités TopLink : principalement orientées optimisation, comme le weaving, optimisation optionnelle du bytecode en fonction d'un certains nombres de paramètres, ou la gestion avancée du cache et de tout ce qui peut éviter les problèmes de n+1. Enfin, un annonce qui fera plaisir à certains, l'introduction d'un lock pessimiste, le tout pour juillet 2008. Bon, ça c'était en gros du Oracle, mais que venait faire le Sun guy là dedans ? Et bien il venait justement nous rassurer ("c'est Eclipse, mais on travaille tous ensemble, etc.") et surtout nous parler de l'intégration dans NetBeans 6.1. Il faut avouer que c'est bien abouti, avec des assistants intelligents, de la config automatique en fonction du serveur d'application, et l'import à partir de la base de données pour donner des classes entités directes. Pour ceux qui ont un peu fait l'impasse sur NetBeans depuis un petit bout de temps ("chez nous on a que du Eclipse/RAD", "c'est du Swing donc ça rame", etc.), je vous invite à profiter de la sortie en début de semaine de la version 6.1 pour ré-évaluer cet IDE, qui peut vous surprendre : ça tourne bien, je peux créer mes JSF facilement, JPA est d'office, et en bonus j'ai UML et BPEL.
Pour finir, une session AMD sur les impacts méconnus de la virtualisation (avec hyperviseur et VMWare ESX) sur nos JVM de serveurs d'application : en effet, en dehors de l'estimation classique d'overhead de 10%, il y a des zone moins faciles au premier abord. En effet, il faut savoir qu'au delà de 986 Mo alloués pour un Linux, la façon de gérer la mémoire de la VM par l'hyperviseur change et peu avoir un impact fort. Bien sur, les I/O disques et réseaux sont à prendre en compte, en déportant sur le SAN pour les premiers et en allouant une carte physique séparée pour chaque VM. Sans oublier l'influence du paramétrage du GC pour qu'il prenne en compte correctement les différents CPU. Rien que des recommandations de bon sens, mais que l'on peut parfois oublier. AMD offre bien sur des techniques pour aider notamment au paging mémoire.