IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Autres SGBD Discussion :

Transaction application vs transaction base de données


Sujet :

Autres SGBD

  1. #1
    Membre averti
    Profil pro
    Inscrit en
    Mars 2010
    Messages
    349
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2010
    Messages : 349
    Points : 439
    Points
    439
    Par défaut 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.

  2. #2
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 137
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 137
    Points : 7 385
    Points
    7 385
    Billets dans le blog
    1
    Par défaut
    Qu'entendez-vous pas une "transaction applicative" ?
    On ne jouit bien que de ce qu’on partage.

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    Mars 2010
    Messages
    349
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2010
    Messages : 349
    Points : 439
    Points
    439
    Par défaut
    Une transaction effectuée a partir d'une application python ou c# pour une base de donnée.

  4. #4
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 137
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 137
    Points : 7 385
    Points
    7 385
    Billets dans le blog
    1
    Par défaut
    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.
    On ne jouit bien que de ce qu’on partage.

  5. #5
    Modérateur
    Avatar de DotNetMatt
    Homme Profil pro
    CTO
    Inscrit en
    Février 2010
    Messages
    3 611
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : CTO
    Secteur : Finance

    Informations forums :
    Inscription : Février 2010
    Messages : 3 611
    Points : 9 744
    Points
    9 744
    Billets dans le blog
    3
    Par défaut
    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.
    Less Is More
    Pensez à utiliser les boutons , et les balises code
    Desole pour l'absence d'accents, clavier US oblige
    Celui qui pense qu'un professionnel coute cher n'a aucune idee de ce que peut lui couter un incompetent.

  6. #6
    Membre averti
    Profil pro
    Inscrit en
    Mars 2010
    Messages
    349
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2010
    Messages : 349
    Points : 439
    Points
    439
    Par défaut
    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:
    Beaucoup 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.
    Source: http://www.dil.univ-mrs.fr/~massat/d...nsactions.html

    En tout cas, je connaissais pas le service DTC.

  7. #7
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 137
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 137
    Points : 7 385
    Points
    7 385
    Billets dans le blog
    1
    Par défaut
    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é).
    On ne jouit bien que de ce qu’on partage.

  8. #8
    Membre averti
    Profil pro
    Inscrit en
    Mars 2010
    Messages
    349
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2010
    Messages : 349
    Points : 439
    Points
    439
    Par défaut
    L'utilité des transactions est très souvent sous-estimé des développeurs, ainsi que des concepteurs de programmes
    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...

    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é).
    Totalement d'accord.

    Merci pour ces éclaircissements.

    P.S: je suis en clavier qwerty. Desolé

  9. #9
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 137
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 137
    Points : 7 385
    Points
    7 385
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par champomy62 Voir le message
    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...
    Je pense que le vrai problème se situe dans la formation (autant celui des élèves que des formateurs).

    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.
    On ne jouit bien que de ce qu’on partage.

  10. #10
    Membre averti
    Profil pro
    Inscrit en
    Mars 2010
    Messages
    349
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2010
    Messages : 349
    Points : 439
    Points
    439
    Par défaut
    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 à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Partie application VS partie base de données
    Par x-or02 dans le forum Modélisation
    Réponses: 4
    Dernier message: 12/10/2007, 15h07
  2. Application locale avec base de données
    Par Drazicz dans le forum Langage
    Réponses: 18
    Dernier message: 09/02/2007, 17h55
  3. Réponses: 1
    Dernier message: 01/02/2007, 16h38
  4. Réponses: 13
    Dernier message: 11/08/2006, 11h08
  5. Application delphi avec base de données multi-utilisateur
    Par richard038 dans le forum Bases de données
    Réponses: 2
    Dernier message: 04/11/2005, 10h11

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo