Monsieur Frédéric Brouard,
Vous intervenez essentiellement dans le forum MySQL pour, par ordre de préférence :
1. Moucher un membre,
2. Dénigrer la base de données MySQL autant que possible
Vous prenez systématiquement la posture du professeur s'adressant à son élève, sans même savoir à qui vous avez affaire, pour affirmer péremptoirement des thèses discutables.
Vous vous autoproclamez autorité supérieure incontestable et vous avez tous les défauts exécrables d'une minorité d'enseignants : vous êtes cassant, humiliant, méprisant et insultant. Pour ma part, j’apprécie particulièrement le qualificatif de 'stupide' dont vous me gratifiez....
Mais venons en au cœur du débat (oui, je me permets de discuter d'égale à égal avec vous, Monsieur le professeur), la localisation des opérations de commit/rollback : externe ou interne aux routines stockées ?
Alors :
Point 1 : une routine (pas seulement une procédure, Monsieur le Professeur) stockée doit être autonome. Sur ce point nous sommes bien d'accord, mais autonome signifie qu'elle doit s’exécuter correctement, indépendamment de qui l'appelle et sans perturber le fonctionnement de l'appelant. Ainsi, lorsque l'on n'est pas en train de jouer à écrire une simple routine monolithique, mais que l'on met en place le cœur de métier complet d'une entreprise sous la forme de routines stockées (vous savez les fameuses bases de données épaisses que vous avez évoquées il y a un certain temps dans un de vos articles), il est clair que les routines stockées s'appellent en cascade. Prononcer un commit dans une routine stockée, alors que l'appelant, qui peut être une autre routine stockée, peut souhaiter poursuivre la transaction en modifiant d'autres données, serait bien évidemment une erreur au regard du A de l'ACIDité souhaitée pour ce traitement.
Point 2 : il faut minimiser la durée de la transaction afin de maximiser la concurrence. C'est vrai mais cet objectif est majoritairement atteint par le fait que l'approche 'base de données épaisse' limite considérablement les échanges lourds sur le réseau, réduit justement drastiquement la durée de pose des verrous, l'échange concernant juste l'opération de commit/rollback n’apparaîssant alors que comme une goutte d’eau dans la mare.
Point 3 : Terminons par le cas de transactions distribuées. Tous les SGBDR majeurs, y compris SQL Server pour lequel vous vouez une admiration sans bornes, gèrent des transactions s'exécutant sur plusieurs nœuds. Dans ce cas précis, l'initiateur du commit ne peut être situé sur tous les serveurs, les nœuds participants sont alors asservis à un serveur sur lequel un coordinateur de commit pilote l'opération de commit. Le coordinateur de commit est donc bien externe à des serveurs sur lesquels s’exécutent des opérations de commit. Les éditeurs de SGBDR aurait-ils implanté des solutions qui conduisent systématiquement à des catastrophes sur le plan des performances transactionnelles ? Non, bien évidemment... Pour ma part, qui ne suit pas "une jeune développeuse", j'en suis convaincue depuis longtemps, j'ai en effet donné des conférences sur les systèmes transactionnels distribués (concepts, théorie et cas concret en production) bien avant 1993, date à laquelle vous avez découvert le relationnel si j'en crois votre biographie.
Pour conclure, je vous remercie de m'avoir exposé ce qu'était une étreinte fatale en agrémentant votre explication d'anglais pour faire sans doute plus savant....
Partager