Les transactions en développement sont souvent négligées, alors qu'il existe des domaines où elles ne devraient pas. Le mot "transaction" vient du commerce, une transaction c'est l'échange de d'un produit ou service contre de l'argent (ou contre un autre produit ou service). C'est une action équitable, personne doit perdre ou gagner dans l'histoire. Dans la plupart des cas, l'intégrité des transactions n'est pas assurée car 1) c'est assez coûteux en ressources, 2) du fait de leur peu d'usage, peu de développeurs savent les utiliser.

Exemple

Imaginons un cas simple : dans un jeu vidéo il existe un supermarché, quand le joueur achète son objet, il faut qu'à la fin de la transaction l'objet soit dans son sac, et que l'argent soit retiré de sa bourse. En cas de problème (soit problème informatique, soit un problème simple tel que le joueur n'a pas assez d'argent) lors de l'échange, il faut que l'objet soit toujours dans le supermarché, et que l'argent soit toujours dans son sac. Il faut donc protéger la séquence : je vérifie la bourse, je vérifie la disponibilité de l'objet, je débite la bourse, je crédite le supermarché, je retire l'objet du stock, je rajoute l'objet dans le sac du joueur. Et il est interdit de s'arrêter en route, si une de ses étapes échoue, il faut que tout revienne comme avant.

Je propose une règle simple pour l'usage des transactions : toute fonction impliquant de l'argent réel de l'entreprise doit être transactionnelle et proprement isolée ("sérialisable"). Ceci est un minimum, d'autres cas peuvent aussi en bénéficier, mais au moins tous ceux-ci doivent être transactionnels.

Petit contre-exemple

Je suis intervenu il y a quelques temps dans une entreprise où le paiement était pilotée depuis du flash sur le navigateur du client. C'est un risque majeur pour l'entreprise. D'une part, le lien entre le navigateur web et le serveur n'assure pas l'intégrité des transactions et le simple fait d'exposer par le serveur web les différentes étapes de la transaction est un risque. Un utilisateur un peu débrouillard aurait tendance à vouloir appeler la partie de la transaction qui met les objets dans son sac en oubliant d'appeler la partie qui débite sa bourse. Il ne faut exposer qu'une seule fonction qui déroule toute la transaction ou échoue de manière atomique.

En résumé

S'il y a de l'argent en jeu, on utilise une transaction en "sérialisable" pour vérifier le montant du compte, transférer l'argent, transférer le bien en une seule étape. Il ne reste plus qu'à lire la doc de votre base de données et celle de votre couche d'accès aux données :)