Le blog du Pere-nono

Ça y est l'article est prêt! Vous pouvez le consulter à travers mon site à l'url suivante http://www.pere-nono.net/dossiers/index.php

Suite à la formation JBoss plusieurs tests s'offrent à moi mais il y en a un qui me tient plus à cœur : le load balancing. Pourquoi cela? Après tout en tant qu'Architecte logiciel certain considèrent que notre problématique et de savoir que cela existe. La technique restant aux administrateur et architecte SI. Personnellement ce n'est pas ma conception et même si je ne prétend pas avoir les mêmes compétences je souhaite savoir de quoi je parle.

Tout d'abord une petite définition du load balancing : ou répartition de charge est une technique utilisée en informatique pour distribuer un travail entre plusieurs processus, ordinateurs, disques ou autres ressources ( source wikipedia ).

Le load balancing peut se faire de différentes manières :

• hard : solution permettant de résister à la plus forte charge, elle aura des problèmes en cas de répartition sur un protocole haut niveau à session,
• soft : permet de facilement gérer des répartition de charge avec respect de session.

Pour mon test, je me suis intéressé uniquement à la partie logiciel avec la configuration la plus courante dans le monde java :

• deux serveurs JBoss ( ici avec des configurations différentes mais une application commune, habituellement les deux serveurs seront totalement iso )
• un serveur apache sur lequel j'ai activé le module mod_jk.

Résultat, j'ai pu répartir la charge et vérifier dans la console JMX JBoss que les requêtes étaient bien avec affinité de session. Puis j'ai touché les réglages pour assurer la continuité de service en cas de panne d'un serveur JBoss et son retour dans le SI quand le serveur est relancé.

J'écris actuellement un document autour de ces essais que je publierais soit sur un site officiel, soit sur mon site personnel.

Plusieurs cas nécessitent de ne pas laisser hibernate gérer ce que l'on nomme la partie DDL de la base de données. Autrement dit la création de la structure ou metadonnées. Pourquoi cela? Parce que :

• on utilise qu'une partie de la structure,
• on veut ajouter des optimisations particulières,
• voir que certaines tables n'en sont pas ( utilisation des vues ).
  

Dans tout ces cas, il faut faire attention car le plus souvent on va aller mettre dans le fichier persistence.xml la ligne suivante :

<property name="hibernate.hbm2ddl.auto" value="" />

Problème, peu de gens en sont conscients mais cela désactive la validation de la base par rapport au mapping déclaré à Hibernate :

• cohérence des types de champs,
• cohérence des liaisons bidirectionnelles,
• test des clés étrangères.

Très concrètement lorsque hibernate se lance, il ne vérifie plus de façon fine les types et va convertir à la volée. Ceci avec certaines fois avec un risque de perte de précision. Imaginons que vous ayez un entier dans votre classe java et un varchar en base de données. Sans validation, pas de soucis il convertit et en base vous aurez votre entier en chaine de caractère. Question : que se passe t'il au niveau de la base si elle doit accueillir 5 caractères et que vous en envoyez 8??? Et bien cela dépendra de la base de données, certaines refuseront l'insertion d'autres vont tronquer le résultat.

Autre problème, sans validation et j'ai pu le vérifier, Hibernate ne crie pas si vous représentez une relation bidirectionnel avec un OneToOne d'un côté et OneToMany de l'autre. Vous en conviendrez cela peut s'avérer très grave. Pourquoi cela? En fait hibernate n'a besoin que d'une des deux relations pour représenter les liens entre les objets ( l'un des liens se fait par mapby or celui ci n'est pas utile à Hibernate pour travailler ).

Maintenant vous en conviendrez mieux vaut un mapping validé dont les erreurs sont lévées au plus tôt et surtout qui ne masque pas par un effet de manche une erreur de mapping. Celle-ci pouvant à tout moment entrainer une erreur plus grave qui invalidera le contenu de la base. Pour cela il vous est donc conseillé d'utiliser la configuration suivante :

<property name="hibernate.hbm2ddl.auto" value="validate" />

Celle ci n'écrase jamais le contenu de la base, ni ne la change. Par contre, la routine de vérification des informations entre le mapping hibernate et la base sera effectuée au chargement d'hibernate et vous indiquera TOUTE les erreurs et pas uniquement les erreurs à l'exécution comme précédemment.

Formation JBoss JB336 sur l'administration d'un serveur JBoss finie. Vraiment très intéressante avec un intervenant très bon et très calme. Dommage que nous ayons eu un souci matériel et que j'ai du utiliser VirtualBox pour finir la formation. Ceci m'a posé des soucis en mode cluster. En tout cas que de bonnes choses et d'éclaircissements, il ne reste plus qu'à tester tout cela à la maison avant une certification et surtout une rapide mise en pratique je l'espère.