Version imprimable
Les transactions (suite d'opérations atomiques) peuvent elles être gérées dans la BLL de manière efficace et performante ? N'est ce pas trop lourd ?
La DAL n'est elle pas le lieu pour les transactions ?
Ou plutôt les PS du SGBD (question performance et gestion auto par le SGBD .. commit ... rollback) mais là on perd la notion d'objet et de réutilisabilité ?
MERCI
La notion de transaction est une notion métier pas d'accès aux données. En général, au sein d'une seule transaction, on fait plusieurs accès aux données en lecture/écriture.
Donc lors d'un échec d'accès aux données il faut gérer soit même le rétablissement des données à l'initiale ?
Cela se fait en effectuant un rollback sur la transaction, soit de façon intentionnelle, soit automatique (par un aspect par exemple).
Bien que plusieurs écoles existent, il me semble plus approprié de démarquer les transactions au niveau BLL (de façon à réunir au sein d'une unique transaction un ensemble d'accès qui concourent à un but métier bien identifié).
Mais que les transactions soient sure et efficace il faut qu'elles soient au plu près du serveur donc dans une PS ... sinon gare au dead loack !
Donc l'aspect métier se trouve donc dans le SGBD.
Cela me parait contraire à la POO (réutilisabilité ...).
Quelle est la bonne solution ?
C'est l'objet d'un long et mouvementé débat qui voit l'affrontement de deux visions. Celle que tu mets en avant, ou pour des question de performance ou de fiabilité, on exploite au maximum le potentiel de la base de données, et une autre vision qui consiste à faire reposer sur le sgbd la seule responsabilité de la persistance de l'information, sans aucune autre fonctionnalité métier.Citation:
Envoyé par brice01
Pour le problème qui t'inquiète, lorsque la connexion avec le sgbd s'interrompt, il y a normalement libération des ressources. De ce fait, j'ai du mal à voir le deadlock dont tu parles ?
Issue de SQLPro :Citation:
1.7. Où placer les transactions ? Sur le serveur ou sur le client ?
OUI, mais... on peut gérer des transactions soit dans des procédures stockées au sein du serveur, soit dans du code client... Qu'est ce qui est préférable ?
L'idée de manipuler des transactions depuis un code client (VB, Delphi, Java, C++...) est séduisante mais "casse gueule" et peut entraîner le pire du pire : un blocage total du serveur. En effet dès que l'on entame une transaction, le SGBDR pose les verrous adéquats sur les ressources visées par la procédure. Si le client perd la main sur son code et ne provoque jamais de COMMIT ou ROLLBACK, les ressources ne sont pas libérées et entraînent l'impossibilité pour les autres utilisateurs d'accèder aux données vérouillées. C'est pourquoi une logique transactionnelle doit toujours être exécutée au plus près du serveur et non sur le poste client, à moins que vous ayez prévue l'artillerie lourde : poste sur onduleur on line ou réseau électrique sur alimentation secourue, OS hyper stable, anti virus, etc...
De plus, il convient que la procédure ne soit jamais en attente d'une manipulation de l'utilisateur (comme une demande de saisie ou de confirmation) car toute attente bloque les ressources un certain temps et met en attente d'autres utilisateurs. C'est alors le château de carte, chaque utilisateur attend qu'un autre libère les ressources et cela peut entraîner le blocage total du SGBDR, par exemple un verrou mortel...
C'est pourquoi on veillera à placer les transactions, soit dans une procédure stockée (l'idéal en terme de sécurité et d'intégrité) soit dans des objets métiers appelés par une serveur d'application ou d'objet aussi bien sécurisé que le serveur SGBDR et dans un réseau connectiquement proche.
http://sqlpro.developpez.com/cours/s...chniques/#L1.7
Donc la vision qui l'emporte c'est celle du développeur objet car c'est qui décide de la structure de son code.
A moins qu'il travaille en étroite collaboration avec un spéciale SQL et là il y aura un choc de vision différente, peut être sans issu.
Quelles sont donc les pratiques les plus courantes ?
MERCI