Passer au contenu principal

De nombreuses applications Java/JEE utilisent les bases de données notamment pour stocker leurs propres datas. Et pour ce faire, beaucoup d’entre elles utilisent ce qu’on appelle les transactions.

Celles-ci permettent d’assurer une certaine cohérence de ce qui est sauvegardé en base, en appliquant les principes suivants :

  • Atomicité : la séquence d’opérations transactionnelles est une et indivisible. Autrement dit soit toutes les opérations de la transaction réussissent, soit l’une d’entre elles échoue et l’ensemble de ces opérations est annulé.
  • Cohérence : la cohérence des données doit être établie dans tous les cas, autrement dit avant les transaction les données sont supposées être cohérentes et après elles le sont, même si entre les deux il y a eu un crash système.
  • Isolation : les données écrites lors de la transaction le sont indépendamment des données qui auraient pu être écrites durant le temps d’exécution de celle-ci.
  • Durabilité : une fois la transaction réalisée, le système est dans un état stable durable. Si elle a échoué, il est rétabli à l’état précédent la transaction.

On désigne sous l’acronyme ACID ces principes.

Les transactions, un concept nécessaire mais à utiliser avec parcimonie

En plus des caractéristiques énoncées ci-dessus, les transactions fonctionnent sur le principe de l’exclusion mutuelle qu’on retrouve dans les contextes multithread. C’est ainsi qu’au cours d’une transaction, des lignes de certaines tables voire des tables entières peuvent être verrouillées, et si vous en abusez cela va créer de nombreuses contentions au sein de votre application voire des deadlocks.

Par conséquent, il convient d’utiliser les transactions uniquement pour des opérations en écriture, et pas pour des opérations de lecture seule. Vous pouvez tout à fait avoir besoin dans le cadre d’une transaction de lire des informations en base, mais si vous ne faites que lire, ne les utilisez pas, sous peine de voir les performances de votre application s’effondrer.

L’API de gestion transactionnelle en JEE : JTA

L’API de gestion transactionnelle en Java/JEE est JTA. Cette dernière est dans les faits assez difficile à maîtriser, aussi les frameworks les plus courants tels que Spring ou les EJB l’implémentent par l’intermédiaire de l’AOP. Aussi globalement vous n’aurez pas à vous en occuper directement. En fait vous ne le ferez que par annotation. Voici le lien pour Spring et celui pour les EJB.

Les niveaux transactionnels dans les applications JEE

Les différentes annotations possibles pour les méthodes sont les suivantes :

  • Required : si votre méthode est invoquée en dehors d’un contexte transactionnel, une nouvelle transaction est créée pour votre méthode, sinon elle reste dans la transaction courante.
  • RequiresNew : une nouvelle transaction est créée pour votre méthode même si celle-ci était déjà invoquée dans un contexte transactionnel.
  • Supported : si votre méthode est invoquée dans un contexte transactionnel, la transaction continue dans cette méthode. Sinon, aucune nouvelle transaction n’est créée pour votre méthode. Ce niveau est à privilégier pour les opérations en lecture.
  • NotSupported : si votre méthode est invoquée dans un contexte transactionnel, la transaction en cours est interrompue le temps d’exécuter votre méthode puis reprend après la fin de celle-ci.
  • Mandatory : si votre méthode n’est pas invoquée dans un contexte transactionnel, une exception est levée.
  • Never : si votre méthode est invoquée dans un contexte transactionnel, une exception est levée.

Et au niveau de la base de données

La base de données celle-ci doit être également configurée pour gérer les transactions d’une manière plus ou moins rigoureuse. Et là encore la configuration plus ou moins laxiste aura un impact direct sur les performances. Cela dit le sujet dépasse cet article aussi pour les plus motivés vous pouvez aller voir ou encore sur l’ouvrage Enterprise Javabeans 3.1 de chez O’reilly, dans le chapitre sur les transactions.

Cet article vous a plu ? Vous aimerez sûrement aussi :

Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.

Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.

Son Twitter Son LinkedIn

Rejoignez la discussion Un commentaire

Laisser un commentaire