Bonjour à tous,
J'avais lu sur le forum developpez.com qu'une transaction applicative était différente d'une transaction dans une base de données.
Auriez-vous plus d'infos à ce sujet ?
Merci.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Transaction application vs transaction base de données
Bonjour à tous,
J'avais lu sur le forum developpez.com qu'une transaction applicative était différente d'une transaction dans une base de données.
Auriez-vous plus d'infos à ce sujet ?
Merci.
Qu'entendez-vous pas une "transaction applicative" ?
Une transaction effectuée a partir d'une application python ou c# pour une base de donnée.
Euh...
C'est un peu vague...
C#, pour ne pas parler de Python que je ne connais pas, permet d'utiliser des transactions du SGBD choisi.
Il n'y a pas la moindre différence entre une transaction "C#" et une transaction SQL, dans la mesure où l'objet gérant la transaction dans C# n'est qu'une interface avec le SGBD, qui est le seul et unique à faire la transaction.
Preuve en est, la transaction en C# est créée à partir de l'objet IConnection ouvert sur la base de données, et sa portée se limite à cet objet : elle ne peut influer sur les objets en mémoire de C#, pas plus que sur les requêtes transitant par un autre objet IConnection, même si cet objet pointe sur la même base de données avec les mêmes informations de connexion.
Si je comprend bien la question, les "transactions applicatives" sont utiles dans le cas où il y a plusieurs systèmes impactés par une requête (systèmes = bases de données, queues, etc.). En général on parle de multi-commit, au moins un par système.
Le service DTC (Distributed Transaction Coordinator) est utilisé par exemple, ce qui permet de garder de la cohérence : si quelque chose plante, on annule la transaction applicative et on rollback sur les différents systèmes. À la base, ce service`(DTC) est fourni par Microsoft mais il est compatible avec les principaux SGBDR du marché dont Oracle.
Dans le cas d'une application mono base de données, l'utilisation des transactions directement au sein du SGBD est suffisante.
Desole si la question est un peu vague, j'avais pas plus d'informations par rapport a cela.
J'ai trouve sur un site web:
Source: http://www.dil.univ-mrs.fr/~massat/d...nsactions.htmlBeaucoup de traitements métiers nécessitent une série d'interactions avec l'utilisateur entrecoupées d'accès à la base de données. Dans les applications web et les applications d'entreprise, il n'est pas acceptable qu'une transaction de base de données se déroule le temps de plusieurs interactions avec l'utilisateur.
La couche applicative prend dont en partie la responsabilité de maintenir l'isolation des traitements métier. C'est pourquoi, nous appelons ce processus une transaction applicative. Une transaction applicative pourra s'étendre sur plusieurs transactions à la base de données. Elle sera atomique si seule la dernière des transactions à la base de données enregistre les données mises à jour, les autres ne faisant que des accès en lecture.
La seule statégie remplissant les critères de concurrence et scalabitité élevées est le contrôle optimiste de la concurrence en appliquant des versions aux données : on utilisera par la suite le néologisme versionnage. Hibernate fournit trois approches pour écrire des applications basées sur la concurrence optimiste.
En tout cas, je connaissais pas le service DTC.
Ok, donc dans ce cas, on ne parle pas de MSDTC, mais bien de bidouillage infâme côté applicatif.
Pour moi, les deux sont complémentaires.
Pour prendre l'image d'une écriture comptable, comme la seconde détaillée dans le lien ci-dessous :
http://www.l-expert-comptable.com/sa...es-de-tva.html
Débit : 1 écriture
Crédit : 3 écritures
Pour que les écritures comptables soient correctes, il faut ABSOLUMENT qu'à tout moment SUM(DEBIT) = SUM(CREDIT)
C'est la base même de la comptabilité.
Par conséquent, en SQL, on utilisera intuitivement une transaction qui effectue les 4 écritures.
Seulement voilà. Dans une application, web qui plus est, on va souvent éclater ces différentes écritures en un wizard, avec plusieurs pages, et cela peut prendre un certain temps à l'utilisateur pour tout remplir.
Le point négatif d'une transaction, c'est qu'elle pose des verrous dans la base, ce qui peut conduire à des lenteurs, voir même des deadlocks.
Donc le développeur va faire une "transaction applicative" (j'aime pas ce terme, car c'est pas une transaction).
C'est à dire que :
- Soit il va écrire les 4 écritures au fil de l'eau, dans une table de travail, avant de les recopier au sein d'une transaction SQL au moment de la validation finale
- Soit il va écrire les 4 écritures au fil de l'eau, avec un flag "en cours de saisie", qu'il va mettre à jour "validé" au sein d'une transaction au moment de la validation finale
Soit toute autre solution, plus ou moins élégante (très généralement affreuse) garantissant plus ou moins bien l'intégrité des données (généralement aucune garantie).
L'utilité des transactions est très souvent sous-estimé des développeurs, ainsi que des concepteurs de programmes. Par conséquent, la partie "transaction applicative" est généralement un affreux sac de noeuds ne garantissant absolument rien : ce n'est pas parce que le programme a vérifié "avec ses propres règles" que les données qu'il souhaite écrire dans la base sont bonnes, qu'elles le sont d'un point de vue intégrité base de données.
Pour ma part, je conseille de travailler totalement déconnecté de la base pour la partie "transaction applicative", et effectuer une transaction SQL au moment où on va pousser les données validées dans l'application vers la base de données. Cela permet de garantir l'intégrité au moment de l'enregistrement dans la base.
Pour moi, la transaction SQL ne doit jamais être écartée dès qu'il y a plus d'une ligne à insérer dans la base (pour une seule ligne, y'a moins d'intérêt, puisqu'une micro transaction implicite est systématique lorsqu'on effectue une requête unitaire (un insert ou un update ne peut pas se faire à moitié).
Peut-être que le temps laisse aux développeurs ne leurs permet pas d'implementer cela correctement. D'ailleurs connaissaient vous un middleware qui permet de faire cela automatiquement ou il faut refaire la meme plomberie a chaque nouvelle application ? J'ai deja été confronte a ce problème...L'utilité des transactions est très souvent sous-estimé des développeurs, ainsi que des concepteurs de programmes
Totalement d'accord.Pour moi, la transaction SQL ne doit jamais être écartée dès qu'il y a plus d'une ligne à insérer dans la base (pour une seule ligne, y'a moins d'intérêt, puisqu'une micro transaction implicite est systématique lorsqu'on effectue une requête unitaire (un insert ou un update ne peut pas se faire à moitié).
Merci pour ces éclaircissements.
P.S: je suis en clavier qwerty. Desolé
Je pense que le vrai problème se situe dans la formation (autant celui des élèves que des formateurs).Envoyé par champomy62
Les transactions sont habituellement présentée en toute fin de cursus, sous forme de "c'est super bien, mais c'est super compliqué".
Du coup tout le monde s'empresse de ne pas écouter, et surtout d'oublier le peu qu'il a entendu.
Pourtant, au final, une transaction, ça se traduit par 2 lignes de code (un début de transaction, et une fin).
Il est rare qu'on doive gérer dans le code le rollback, il est habituellement implicite lorsqu'une erreur survient.
Les transactions sont présentées comme un moyen de travailler en mode "brouillon" et pouvoir revenir en arrière.
Pour moi, c'est avant tout la garantie que les données sont synchrones : lorsque la commande est valorisée, le montant de l'entête est bel et bien égal à la somme du total des montants des lignes.
On peut faire la même chose sans transaction.
Sauf qu'au moment où on va requêter la base de données, si quelqu'un est en train de travailler dans, on va se coltiner des résultats faux.
Alors qu'un simple "begin trans" à la création de la commande, et un "commit" au moment de sa validation permet de garantir qu'on n'ira pas lire les données en cours de travail.
C'est pas faux non plus. Dans mon cursus de BTS, je n'ai meme pas vu les transactions ou les access concurrentielles. J'ai tout appris par moi-meme ...
Merci pour vos réponses.
Répondre avec citation
Partager