All posts in Hibernate

Hibernate dirty checking

Les ORM (Object-Relational Mapping) sont aujourd’hui des technologies matures ; l’essentiel d’Hibernate a été versé au standard Java EE au travers de la spécification JPA qui en est maintenant à sa deuxième version.
Les réfractaires à la technologie, qui préfèrent encore utiliser directement l’API JDBC ou (moindre mal) les templates JDBC de Spring, sont aujourd’hui de moins en moins nombreux. Malgré tout, s’il est donc vrai qu’un ORM apporte une solution élégante à la problématique de persistance de nos applications, il faut aussi admettre qu’en déléguant une partie du travail d’interaction avec la base de données à ces outils nous perdons un peu en contrôle ce qui introduit de nouvelles difficultés. Parmi celles-ci il y a la bonne prise en compte du « dirty checking ».

Le « dirty checking » est un mécanisme d’Hibernate qui consiste à lister parmi les objets attachés ceux qui ont été modifiés pour ensuite propager ces modifications en base. Ce comportement du framework doit être bien compris car il peut être source d’effets secondaires indésirables.

Hibernate peut lancer une opération de « dirty checking » à plusieurs occasions :

  • Lors d’un flush, qui intervient au moment du commit de la transaction ou d’un appel explicite par EntityManager.flush(),
  • Juste avant l’exécution d’une requête de type « select ». Ce cas de figure peut sembler moins évident que le premier mais la raison est relativement simple : la requête sera exécutée au niveau de la base de données, il est par conséquent capital que les données modifiées dans la transaction en cours qui peuvent influencer le résultat de la requête soient « flushées ».

Si la plupart du temps, le « dirty checking » se fait dans la plus grande transparence sans que le développeur n’ait à s’en soucier, il arrive aussi que son déclenchement soit gênant. Par exemple dans le cas de traitement de masse où le nombre d’objets attachés est très important cette opération peut pénaliser fortement les performances. Par ailleurs, si l’on souhaite avoir la main sur l’ordonnancement des requêtes SQL, il est embêtant qu’une simple recherche JPQL déclenche une série de requêtes de type « update » à la suite d’un « dirty checking ».

Comment faire alors pour maîtriser la propagation des modifications dans la base et éviter les traitements de « dirty checking » intempestifs ?

Hibernate étant un framework souple et paramétrable, il offre pas mal de possibilités au développeur pour gérer cela : on peut travailler dans un mode « read only », on peut aussi utiliser la classe StatelessSession qui est spécialement pensée pour dérouler des opérations en bloc (sans « dirty checking » automatique). Si l’on préfère, probablement à raison, rester sur le standard JPA, il suffit de positionner le « flush mode » comme ceci :

EntityManager.setFlushMode(FlushModeType.COMMIT);

Ainsi les objets ne seront synchronisés avec la base de données qu’à la fin de la transaction, au moment du commit. Évidemment, il faut là aussi être sûr de son coup, il convient de bien vérifier qu’aucune requête de sélection ne sera perturbée par ce flush tardif.

Portail Liferay avec GWT intégré en SOA pour Pierre et Vacances

Aujourd’hui je viens vous faire partager une très belle expérience projet. Je vous parlerai donc d’un projet que nous avons réalisé pour notre client Pierre et Vacances, qui a su nous faire confiance jusqu’au bout pour le développement et l’infogérance de son extranet commercial.

Faire des choix en matière d’architecture logiciel en 2010 peut être un exercice difficile, c’est pourquoi l’approche de DocDoku en matière de choix techniques est basée sur les principes suivants :

  • pragmatisme, dans le choix des langages et des technologies,
  • ouverture d’esprit, nous effectuons une veille technologique permanente,
  • mise en contexte, chaque problème étant différent, les réponses à apporter doivent l’être également,
  • industrialisation, il ne s’agit pas de s’emparer de la toute dernière nouveauté mais de bâtir des solutions robustes, matures et maintenables,
  • respect des standards établis, pour garantir la pérennité des applications, et maximiser l’investissement consenti par nos clients, nous nous appuyons sur les standards unanimement reconnus.

Dans le cadre de l’extranet commercial développé pour Pierre et Vacances, les grands principes architecturaux retenus ont été les suivants :

  • utilisation du composant portail open source Liferay permettant un gain de productivité certain en particulier sur les modules génériques (droits d’accès, profils utilisateurs, agenda, publication de news…) mais respectant également la JSR 286, norme de communication entre le portail et les applications qui y sont hébergées, supportée par de nombreux éditeurs (IBM, Sun, Oracle, RedHat). Ceci permet de surcroît de limiter notre dépendance vis-à-vis d’une solution portail en particulier.
  • développement d’une architecture en couches permettant notamment de découpler les composants les uns des autres et de les faire évoluer indépendamment.  Une séparation en couches permet d’adapter en effet l’architecture physique en fonction des besoins de distribution pour une bonne capacité à monter en charge.  Une architecture n-Tiers en 4 couches distinctes a été choisie :
    • La couche d’accès aux données avec JPA-Hibernate dont le rôle est la connexion à la base de données, l’exécution des requêtes ou l’appel des procédures stockées.
    • La couche de service EJB3 et JAX-WS-Metro, ensemble des règles métiers et processus de l’application. Cette couche sera implémentée en Java via des composants transactionnels.
    • La couche métier POJO qui constitue le diagramme de classes des entités (le modèle objet).
    • La couche de présentation avec GWT et Portlet Liferay : l’interface utilisateur affiche les résultats traités par la couche métier.  Ici le framework Ajax GWT a été choisi pour à la fois offrir une ergonomie poussée et une forte maintenabilité.
  • mise en place d’une architecture de type SOA pour pouvoir exposer de façon universelle les fonctions de l’extranet pour les futures applications du SI.

Tout ceci est en production évidemment depuis la fin octobre 2009.

Agilement.