Le blog du Pere-nono

vendredi 27 novembre 2009

Transaction, ReadOnly et Hibernate

Hier petite decouverte en me plongeant dans les transactions, spring et hibernate.

1er découverte : lorsque l'on travaille avec les transactions par Spring, il est important de gérer les ouvertures de transaction en un seul point sur l'arbre d'execution. Je m'explique si vous mettez l'annotation @transaction(readOnly=true) sur une methode A et que celle-ci appelle la methode B qui elle change un parametre sur les transactions @transactional(propagation.Mandatory). Au moment ou l'on passe dans la methode B la transaction prend le paramètre de propagation et repasse tout les autres dans leurs valeurs par défaut. Nous perdons donc le readOnly=true, la valeur par défaut étant readWrite.

2e découverte : La sémantique du readOnly pour les transactions n'est pas obligatoirement ce que l'on croit. Et oui celui-ci ne represente en fait que le passage dans une politique optimisant les flushs dans le cadre de la lecture. Une ecriture sur une transaction readOnly va donc passer avec Hibernate ( attention cela semble ne pas être le cas avec tout les ORM et particulièrement TopLink ).

vendredi 13 novembre 2009

Hibernate tools et les dates

Aujourd'hui petite découverte concernant l'outil hibernate tool.
Après de nombreux tests sur une application JAVA6/Hibernate3/Oracle8i ou je developpe, je viens de m'apercevoir que la génération de cet outil n'est pas toujours exacte ( en tout cas dans notre cas ). Ainsi au niveau des colonnes de types DATE sous oracle, il choisit d'utiliser un hibernate type : date. Problème, ce dernier ne tient pas compte des heures minutes seconde et passe tout à zero. Il est donc important de reprendre chacun des champs date et de remplacer le type hibernate par timestamp et en supprimant la propriété length.
Miracle vous avez maintenant l'ensemble des données alimentant votre objet java de type Date et l'affichage qui se fait correctement : 13 nov. 2009 14:16