Discussion :

[Dunkhan]

Bonjour,

Je suis entrain d'étudier Mysql, et après avoir lu les transactions, procédures stockée, fonction et trigger.

Bien que je comprenne l'utilité, et le fonctionne interne de chacun des points, j'avoue être un peu perdu sur quand utiliser quoi.
Par exemple, dans les transactions, on voit que l'on peut faire appel aux verrous et leur utilités me parait tout à fait clair, mais qu'en est il dans les fonctions alors??

J'ai beau chercher sur le net, apparemment on ne peut pas utiliser les transactions au sein des fonctions, ou plus précisément, on ne peut pas faire de COMMIT dans une fonction.. et est il possible de faire l'inverse, faire appel a une fonction ou procédure stockée dans une transaction, vu que l'on peut renvoyé une valeur dans une variable (OUT INOUT) et donc potentiellement l'utiliser dans.. quoi?? une autre fonction, une procédure??

Autre exemple, dans un trigger, je peux préciser ce qu'il se passerait lors d'une modification d'une table, mais dans les transaction on me parle de verrous qui empêche de modifier des données si une autre sessions a posé un FOR UPDATE sur une (ensemble de) ligne(s), mais d’après ce que je lis des exemples que je trouve, les triggers ont l'air d’être utiliser sans aucune vérification au préalable.. ??!

Comment fait on pour poser dans verrous et intervenir sur des données dans une fonction, une procédure stockée, ou un trigger, tout en étant sur de ne pas laisser d'autre sessions changer les dites données dans notre dos??


Comme je le disais plus haut, je m'y perd un peu, et je crois que je mélange un peu tout ca.



Est ce que qlq'un aurait la gentillesse de m'expliquer a quel moment, et dans quelle sens on se sert de quoi dans la gestion au quotidien d'une base de données??!

[escartefigue]

Par exemple, dans les transactions, on voit que l'on peut faire appel aux verrous et leur utilités me parait tout à fait clair, mais qu'en est il dans les fonctions alors??

Une transaction, c'est l'ensemble des opérations, validation incluse, qui permettent de faire passer la base de données d'un état à un autre tout en conservant la cohérence de la base.
La plupart des SGBD étant multi-utilisateurs *, la gestion des verrous est ce qui permet à chaque transaction de ne pas être impactée par les autres utilisateurs. Le niveau d'isolation, précisé au niveau transaction, permet de choisir le niveau de partage des données avec les transactions concurrentes.
* Le problème peut se poser aussi avec une situation mono-utilisateur mais multi-thread

Une transaction peut utiliser des requêtes, des fonctions ou des procédures stockées.
Que les requêtes soient appelées directement ou au travers de fonctions ou de procédures stockées, elles posent des verrous plus ou moins larges
Mais c'est la transaction qui doit gérer la cohérence de l'ensemble des mises à jour. C'est la raison pour laquelle c'est la transaction qui fait le COMMIT ou le ROLLBACK pour libérer les verrous après mise à jour et permettre aux autres utilisateurs, à leur tour, de faire leurs propres modifications.

Autre exemple, dans un trigger, je peux préciser ce qu'il se passerait lors d'une modification d'une table, mais dans les transaction on me parle de verrous qui empêche de modifier des données si une autre sessions a posé un FOR UPDATE sur une (ensemble de) ligne(s), mais d’après ce que je lis des exemples que je trouve, les triggers ont l'air d’être utiliser sans aucune vérification au préalable.. ??!

Le trigger ne s'exécute que si la requête s'exécute, et si la requête s'exécute c'est que les verrous ont été vérifiés !

Comment fait on pour poser dans verrous et intervenir sur des données dans une fonction, une procédure stockée, ou un trigger, tout en étant sur de ne pas laisser d'autre sessions changer les dites données dans notre dos??

Les verrous sont posés automatiquement par les requêtes, vous pouvez aussi poser un verrou explicitement sur une table complète.
Par défaut, une requête en lecture pose un verrou qui autorise le partage en lecture avec d'autres transactions
A l'inverse une requête en mise à jour (DELETE ou UPDATE) pose systématiquement un verrou exclusif.
Si la transaction essaye de poser un verrou exclusif pour mise à jour sur des lignes déjà verrouillées par une autre transaction, alors il y a attente de libération et éventuellement plantage si la libération tarde trop ("time out")

[Artemus24]

Salut Dunkhan.

Par exemple, dans les transactions, on voit que l'on peut faire appel aux verrous et leur utilités me parait tout à fait clair, mais qu'en est il dans les fonctions alors??

Ne confondez pas les transactions et les verrous, ce sont deux choses différentes dans le fonctionnement de MySql.

Les fonctions, comme les procédures stockées sont aussi impactées par les verrous.
Sauf que les verrous sont faits au moment de la lecture, donc bien avant le traitement de ceux-ci.

J'ai beau chercher sur le net, apparemment on ne peut pas utiliser les transactions au sein des fonctions, ou plus précisément, on ne peut pas faire de COMMIT dans une fonction...

Le démarrage d'une transaction se fait avant l'exécution de votre requête, à savoir quand on fait un "start transaction ...".

La fin de la transaction se fait quand la requête est terminée, sauf que pour l'instant, les données ne sont pas encore enregistrées dans vos tables.
Deux choix se proposent à vous, soit une validation "commit" soit un rejet "rollback".
A l'issu de ces deux choix, vous rendez la main au SGBDR MySql.

Il n'y a aucun intérêt à faire un "commit ou un rollback" dans une fonction ou une procédure stockée car vous êtes déjà dans une transaction.
Et pour bien comprendre le fonctionnement, une transaction permet de valider totalement ou rejeter totalement vos données.
Pourquoi ? A cause de l'intégrité de vos données.
Si dans une table vous modifiez des données qui sont en relations avec une autre table où vous modifiez aussi les données, vous comprenez que l'ensemble doit être validées ou rejetées.
Si vous validez la première table et rejetés la seconde table, vous vous retrouvez avec un désiquilibre, ce qui va provoquer un problème d'intégrité de votre base.

et est il possible de faire l'inverse, faire appel a une fonction ou procédure stockée dans une transaction, vu que l'on peut renvoyé une valeur dans une variable (OUT INOUT) et donc potentiellement l'utiliser dans.. quoi?? une autre fonction, une procédure??

Aucun intérêt. En gros, vous n'avez pas compris comment fonctionne une transaction.

mais d’après ce que je lis des exemples que je trouve, les triggers ont l'air d’être utiliser sans aucune vérification au préalable.. ??!

C'est normal car comme le dit Escartefigue, l'appel au déclencheur se fait quand la requête s'exécute et la requête s'exécute quand le verrou l'autorise.
Vous devez voir cela comme une série d'encapsulation, dont le déclencheur serait le plus interne et le verrou le plus externe.

Comment fait on pour poser dans verrous et intervenir sur des données dans une fonction, une procédure stockée, ou un trigger, tout en étant sur de ne pas laisser d'autre sessions changer les dites données dans notre dos??

Cela se fait en partie dans le fichier "my.ini", par exemple en définissant le mode transactionnel que vous allez choisir, par exemple : ""transaction-isolation = SERIALIZABLE".
Cela signifie que toutes vos lectures seront sérialisées.

Mais cela n'indique pas comment vont se faire vos verrous.
Avant de lancer la requête, vous definissez vos verrous, par exemple : "lock tables ...".
Et pour déverouiller les tables : "UNLOCK TABLES".

J'ai oublié de préciser que cela ne concerne uniquement le moteur "InnoDB".
Et qu'il existe plusieurs formes d'écritures pour les vérrous, pas uniquement les deux que j'ai donnée ci-dessus.

Il est difficile de comprendre comment fonctionne les verrous car cela dépend de la façon dont vous allez gérer vos données par la suite.
Le mieux est de nous donner un exemple de ce que vous désirez faire.

@+

[Dunkhan]

Merci a vous deux pour vos réponses!

Je pense que je commence a y voir un peu plus clair.

Je vais essayé de résumer ce que j'ai compris jusqu'ici.


Je lance une transaction dans laquelle je pourrais faire une suite de requêtes.
Ces requêtes peuvent être des procédures stockées et contenir des fonctions (les procédures peuvent aussi contenir des fonctions).

Les verrous sont posé lorsque je fais :
- un SELECT si définis explicitement en "lock in share mode" (lecture partagée) ou en "for update" (écriture exclusif)

- un UPDATE/DELETE et dans ce cas les verrous sont implicite et dépendant de la clause WHERE (si pas de clause WHERE, toutes les lignes sont verrouillées), ou si une des colonnes ne possède pas d'index, toutes les lignes de la colonne utilisée

- un INSERT dans ce cas toutes les lignes utilisées sont verrouillée

- UPDATE/DELETE/INSERT pose automatiquement un verrous de clé suivante.

Tous les verrous dépendent du niveau d'isolation définit dans la configuration de la DB.

La copie/photo de la DB est modifiée.

Je valide, soit un faisant un COMMIT, soit en déverrouillant les tables précédemment verrouillées, ou je cancel en faisant un rolleback.
Les modifications sont réalisées dans la DB pour de bon.


Je n'ai pas d'exemple de ce que je cherche a faire, j’étudie pour passer un examen et je n'arrivais pas a mettre dans l'ordre ce que je lisais

[escartefigue]

Ne confondez pas les transactions et les verrous, ce sont deux choses différentes dans le fonctionnement de MySql.

Pas seulement dans mysql, mais dans tous les SGBD relationnels,

Les fonctions, comme les procédures stockées sont aussi impactées par les verrous.
Sauf que les verrous sont faits au moment de la lecture, donc bien avant le traitement de ceux-ci.

Pas seulement de la lecture, les verrous sont posés pour tout accès, en lecture comme en écriture

[escartefigue]

Tous les verrous dépendent du niveau d'isolation définit dans la configuration de la DB.

Non, tous les verrous ne dépendent pas du niveau d'isolation
L'isolation est définie au niveau de la transaction et les verrous dépendent du type d'accès aux données et des options définies lors ce ces accès, par exemple avec la clause "for update of" lors d'un select

La copie/photo de la DB est modifiée.

Cette assertion n'est pas claire, les copies, si vous parlez des sauvegardes de la BDD, ne sont pas concernées par les verrous ni par les transactions, ce sont des fichiers séquentiels permettant de restaurer la BDD

Je valide, soit un faisant un COMMIT, soit en déverrouillant les tables précédemment verrouillées, ou je cancel en faisant un rolleback.
Les modifications sont réalisées dans la DB pour de bon.

Non la seule façon de valider une transaction, c'est de faire un COMMIT, le ROLLBACKau contraire invalide les modifications

[Artemus24]

Salut Dunkhan.

Je pense que je commence a y voir un peu plus clair.

Je ne pense pas car c'est assez compliquer à comprendre.

Je vais faire un résumé que voici :

1) vous devez désactiver le mode "autocommit" car par défaut il est à "ON".

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

set autocommit = 0;

Si il est à "ON", le mode transactionnel ne sert à rien.

2) le mode transactionnel.
--> https://dev.mysql.com/doc/refman/8.0...ansaction.html

Quelques définitions :

L'instantané (snapshot) est l'état de la base à une heure donnée, et ce, quelque soit les modifications qui ont été faites par les autres utilisateurs après cette heure.

La lecture cohérente (consistent read) consiste à lire ce qui est validé par les autres transactions.

La lecture sale (dirty read) consiste à lire les lignes validées ou non validées par les autres transactions.

Il y a six cas qui sont :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

set session transaction read only

Aucun verrouillage possible. Vous ne faites que des lectures sales. Pas d'instantané.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

set session transaction read write

Verrouillage sur les écritures et lecture sale. Pas d'instantané sur les lectures.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

set session transaction isolation read-uncommitted

C'est la lecture sale, sans instantané.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

set session transaction isolation read-committed

Pas de lecture sale, et l'instantané se fait au moment de la lecture de la ligne.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

set session transaction isolation repeatable-read

C'est la valeur par défaut.
Il s'agit de lectures cohérentes et elles sont verrouillées jusqu'à la fin de la transaction.
L'instantané est fait à partir de l'heure de la première lecture.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

set session transaction isolation serializable

C'est pareil que le repeatable-read sauf que les lectures et écritures sont sérialisées, donc pas de concurrence.
C'est ce que l'on met comme isolation (dans le fichier my.ini) pour obtenir un bon comportement dans le mode transactionnel.

3) démarrage de la transaction.
Il suffit de faire ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

start transaction

4) vos requêtes.
J'entends par vos requêtes, les lectures suivies des mises à jour, et ce, pour une grappe de données afin de ne pas avoir un problème d'intégrité de données.

5) validation ou rejet.
Quand vous avez terminé vos mises à jour sur votre grappe de données, vous avez deux choix en fonctions de votre traitement, soit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

commit

ou soit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

rollback

Ceci est la structure d'une transaction.
Vous constatez, il y a un verrouillage dépendant du mode d'isolation utilisée.

@+

[Artemus24]

Salut Dunkhan.

Les verrous peuvent entrer en conflit avec le transactionnel.
Dans l'ensemble des verrous proposés sous MySql, seul le verrou exclusif (for update) est utile.

1) lecture verrouillé.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select ... for share

Tout le monde peut lire, mais pas modifier la ligne et ce, jusqu'à la validation de la ligne.

2) mise à jour verrouillée (ou verrou exclusif).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select ... for update

La lecture n'est pas autorisée pour les autres utilisateurs, et ce, jusqu'à la validation.
C'est le verrou le plus utilisé sous MySql.

3) verrouillage de la table.
--> https://dev.mysql.com/doc/refman/8.0...ck-tables.html

Il s'agit d'un verrouillage total sur la table. Il y a deux types de verrous :

3-a) en lecture.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

lock tables `ma_table` as t1 read

3-b) en écriture.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

lock tables `ma_table` as t1 write

4) pour déverrouiller toutes les tables.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

unlock tables

On ne peut pas déverrouiller une table en particulier.

5) pour visualiser les tables verrouillées.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

show open tables;

6) il existe des formes d'écritures anciennement qui restent valides uniquement pour la compatiblité ascendante.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT ... LOCK IN SHARE MODE

Attention !
-->le "start transaction" supprime les verrous de tables que vous avez installé précédemment.
--> avec le moteur MyIsam", le verrouillage se fait que sur la table et pas sur la ligne.

@+

[isabelle.letrong]

Bonjour Dunkhan,

Je me permets d'ajouter mon grain de sel dans la discussion et en particulier 2 idées qui sont devenues miennes avec l'expérience de mise en production d'applications entièrement développées, hors interfaces utilisateurs, en routines stockées.

Règle de base N°1 : Ne JAMAIS prononcer un COMMIT ou un ROLLBACK au sein d'une routine stockée.
En effet c'est l'initiateur (celui qui a provoqué directement (procedure ou fonction) ou indirectement (trigger) l'appel à la routine stockée qui doit prendre cette décision.
Je dirais même que, quand on envisage de coder le cœur de métier sous la forme de routines stockées, toutes les transactions doivent être commitées par l'initiateur, notamment parce que le code invoqué a pu journaliser dans des Logs (dans des tables de la base donc...) , les appels qui lui ont été faits. Il importe donc que les Logs soient enregistrés dans la base, ce qui ne peut être fait que si la transaction a été commitée.
Evidemment on en vient immédiatement à la question qui concerne les données qui ont pu être modifiées à tort en cas d'anomalie. Ces mises à jour doivent bien évidemment être invalidées, par l'opération de COMMIT (et non de ROLLBACK). C'est paradoxal mais l'explication vient avec la règle qui suit...
.
Règle de base N°2 : En cas d'anomalie, chaque routine appelée doit rétablir un contexte propre et en particulier, les données telles qu'elles étaient avant l'appel. Ceci se fait au moyen de :
1. du couple SAVEPOINT/ROLLBACK TO SAVE POINT pour ce qui concerne procédures et fonctions
2. de l'envoi d'une exception pour un trigger. L'exception sera alors reçue et traitée dans le code initiateur (une procédure ou une fonction donc) comme décrit en 1.

[SQLpro]

Règle de base N°1 : Ne JAMAIS prononcer un COMMIT ou un ROLLBACK au sein d'une routine stockée.
En effet c'est l'initiateur (celui qui a provoqué directement (procedure ou fonction) ou indirectement (trigger) l'appel à la routine stockée qui doit prendre cette décision.

C'est une règle hautement stupide que l'on trouve hélas souvent chez les jeunes développeurs qui n'ont pas compris l'intérêt des procédures stockée.

En effet une procédure stockée est une routine autonome destinée à assurer un traitement local sur le serveur.
Décider de gérer la transaction depuis l'application induira un allongement considérable de la durée des verrous posés par la transaction. Il s'ensuivra de nombreux blocages, voir des interblocages (aussi appelés étreinte fatale et en anglais deadlock).
En effet, les temps de communication dans les réseaux, sont des temps "longs" comparativement à la durée des requêtes dans un bon SGBDR…
Or en pilotant la transaction de l'extérieur (initialisation et finalisation) cela allonge la durée des verrous des aller-retours réseau (aussi appelés "round-trip" en anglais) alors qu'il est absolument nécessaire de minimiser la durée de la transaction afin de maximiser la concurrence.

Je relève sans arrêt de telles erreurs dans mes audits…

A +

[Dunkhan]

Merci a vous tous pour vos réponses

J'ai réussi mon examen.. fin j'attend les résultats, mais normalement c'est bon :p

Je vais marquer le sujet comme résolus, vu que j'ai eut les réponses à mes questions, mais libre a vous de poursuivre la discussion si vous le voulez..

[isabelle.letrong]

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....

[skuatamad]

Je plussoie isabelle.letrong sur l'ensemble de son intervention et partage totalement son point de vue sur la gestion du COMMIT dans les procédures (à l'exception de procédure appelée depuis une tâche planifiée si le planificateur ne fait pas de COMMIT implicite)

Par défaut, une requête en lecture pose un verrou qui autorise le partage en lecture avec d'autres transactions

Le verrou posé autorise aussi le partage en écriture à moins d'avoir spécifié FOR UPDATE ou FOR SHARE
Locking Reads

[CinePhil]

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.

Je ne suis pas spécialiste du truc mais ne faut-il pas, en ce cas, mettre le commit dans la procédure générale qui appelle les autres et pas dans chaque sous-procédure ?
Le rollback éventuel devrait concerner tout ce qui a été modifié par les sous-procédures puisqu'on est en principe dans la même transaction, non ?

Ce sont là des questions candides de ma part ; n'ayant jamais eu à faire cela.

[isabelle.letrong]

../ne faut-il pas, en ce cas, mettre le commit dans la procédure générale qui appelle les autres et pas dans chaque sous-procédure ?
Le rollback éventuel devrait concerner tout ce qui a été modifié par les sous-procédures puisqu'on est en principe dans la même transaction/..

Sur le fond, il me semble que les notions mêmes de procédures principales et de sous-procédures induisent une rigidité du code et sont donc un frein à sa ré-utilisabilité. Considérer qu'une procédure est principale et ne sera jamais appelée par une instance supérieure participe selon-moi à de la sur-spécification qui n'a pas lieu d'être .

[CinePhil]

Donc, si j'ai bien compris ton point de vue :
1) L'application démarre la transaction
2) L'application appelle la première procédure stockée
3) La procédure en appelle éventuellement d'autres
4) L'application lance le commit ou le rollback et ferme la transaction.

C'est ça ?

[isabelle.letrong]

Pour répondre à Cinéphil,

Oui, c'est cela. L'application peut être celle qui gère l'interface utilisateur en s'appuyant sur un framework mais aussi, plus simplement, un script SQL.
Entre l'ouverture de la transaction et la fin de transaction, l'application aura éventuellement pu appeler plusieurs procédures qui auront chacune retourné un statut de bonne ou mauvaise exécution avec un contexte propre associé : mise à jour prêtes à être commitées ou mises à jour invalidées.
Il va de soi que l'application se gardera bien de laisser une transaction ouverte pendant une phase de saisie.
Il me parait fondamental que les développeurs d'interfaces utilisateur maîtrisent d'abord le concept de transaction avant de maîtriser tout ce qui touche au relationnel qui relève selon moi de la spécialisation.

[Artemus24]

Salut à tous.

Ce qui est hautement stupide, Monsieur SQLPRO, c'est de ne pas savoir ce que représente une grappe de donnée.
On ne valide pas partiellement des données appartenant à un groupe de données juste pour éviter des problèmes de concurrences d'accès.

Autre point dont vous semblez ignorer, c'est l'usage d'une procédure stockée.
Celle-ci concerne des traitements de masse et de ce fait, s'effectuer en batch de nuit quand le serveur MySql n'est plus accessible par les utilisateurs.
Et non en pleine journée comme vous semblez le croire.

Le seul point où je suis d'accord avec vous, concerne la minimisation de la durée de la transaction.
On ne va pas valider chaque grappe de données, ni attendre la fin du traitement pour tout valider, mais trouver un juste milieu dans le nombre de grappes que l'on doit valider.
Le journal n'est pas un fichier extensible à l'infini et faire une validation en fin de traitement n'est pas une bonne idée. Pourquoi ?
Si survient un plantage en cours de traitement, il faut recommencer tout depuis le début. Imaginez que ce batch dure des heures, voilà du temps perdu pour rien.
De ce fait, il faut aussi gérer les points de reprises que vous semblez ne pas connaitre, et dont vous n'avez même pas abordé dans votre critique !

Donc non, on ne met pas de commit ou de rollback dans une procédure stocké.
Et non, on ne lance pas une procédure stockée qui dure des heures en pleine journée.

Vous devez dans une transaction gérer la totalité des grappes et faire une validation disons toutes les N grappes.
Si vous aviez fait un tant soit peu de l'exploitation, vous sauriez qu'une reprise en cas de plantage doit se faire en effectuant un minimum de manipulation.
Et le tout, sans trop perdre de temps, sinon, les batch de nuit peuvent se terminer en début de mâtiné, voire même plus tard.

Donc je suis d'accord avec Mme Isabelle Letrong pour ses remarques !

Ce sont là des questions candides de ma part ; n'ayant jamais eu à faire cela.

Le commit ou le rollback se mettent en fin de validation d'une grappe de données.
La question est de savoir comment se gère une grappe de données dans une procédure stockée.
De ce fait, si vous avez une boucle général et qu'au sein de cette boucle vous gérez une grappe, il suffit de comptabiliser le nombre de grappes, par exemple toutes les dix grapes pour faire une validation.
Le rejet, quant à lui peut se faire dans la grappe elle-même.
Ne pas oublier que vous devez gérer le point de reprise.
Autrement dit, si vous relancez votre procédure stockée, elle doit redémarrer juste après la dernière validation.

Donc ce qui est stupide, c'est de lancer une procédure stockée en pleine journée alors que cela doit se faire la nuit.

Considérer qu'une procédure est principale et ne sera jamais appelée par une instance supérieure participe selon-moi à de la sur-spécification qui n'a pas lieu d'être .

Il ne s'agit de faire un bout de code et considérer que cela soit suffisant pour intégrer un système d'information.
Il fait se poser aussi des tas de questions sur son usage et son exploitation, les points de reprises en cas de plantage et la gestion des erreurs pour redémarrer l'application.
Ainsi on peut aussi créer un fichier de recyclage où l'on y place tout ce qui pose problème durant le traitement.
Cela évite d'une part d'avoir un plantage de l'application et d'autre part de laisser l'utilisateur, le lendemain, gérer le pourquoi du comment, les grappes de données qui n'ont pas été validées.

Il me parait fondamental que les développeurs d'interfaces utilisateur maîtrisent d'abord le concept de transaction avant de maîtriser tout ce qui touche au relationnel qui relève selon moi de la spécialisation.

Le transactionnel ne consiste pas uniquement à ouvrir une transaction et à la fermer avec un commit ou un rollback.

Vous avez la notion de grappe de données qui est hyper-importante et ce, à cause de l'intégrité de vos données, surtout quand on fait des calcules, genre des cumuls.

Mais il y a aussi l'aspect exploitation, c'est à dire l'automatisation qui consiste à rendre cette gestion la plus souple possible, aussi bien pour l'utilisateur qui a en charge le suivi du traitement, mais aussi le pupitreur qui a en charge les batch de nuit.

Je constate que de plus en plus, des notions fondamentales à la bonne marche d'un système d'information sont ignorées, voire méconnues.

@+

[isabelle.letrong]

Artemus24,

Les procédures stockées ne concernent pas que les traitements de masse, loin de là !
D'ailleurs tout l'objet de la discussion portait plutôt sur l'environnement transactionnel au sens commun, justement par opposition aux traitements batchs ou de masse. On commit naturellement également toutes les mises à jour faites dans un contexte d'applications transactionnelles. C'est dans ce contexte précis que les question des verrous et accès concurrents se posent réellement. La question des batchs me semble donc un peu hors sujet pour cette discussion.
Par ailleurs, les points de reprise existent dans MySQL, même s'ils ne font pas tout, j'en ai parlé précédemment, ils se gèrent au moyen de SAVEPOINT/ROLLBACK TO SAVEPOINT...

[Artemus24]

Salut isabelle.letrong.

Les procédures stockées ne concernent pas que les traitements de masse, loin de là !

Vous ne m'avez pas compris du tout.
Je parlais des procédure stockée avec des commit et des rollback, pour des traitements de masse pas des autres.
Sinon à quoi cela sert de mettre des commit et des rollback dans une procédure stockée si la validation peut se faire à l'extérieur ?
Pour la simple raison que l'on balaye la totalité d'une table, donc c'est un traitement de masse.

D'ailleurs tout l'objet de la discussion portait plutôt sur l'environnement transactionnel au sens commun, justement par opposition aux traitements batchs ou de masse.

Je ne suis pas d'accord avec vous sur ce point.
Le transactionnel est le même que ce soit pour un traitement de masse ou une simple mise-à-jour.
Je ne vois pas pourquoi il faudrait faire une distinction dans ces deux cas.

Il y a juste un coté allégé dans la simple mise-à-jour où le point de reprise n'est pas nécessaire.

On commit naturellement également toutes les mises à jour faites dans un contexte d'applications transactionnelles.

Je ne comprends pas votre remarque.
Soit on est dans un autocommit et dans ce cas chaque mise à jour est validée, sans avoir la possibilité de faire un rollback.
Soit on fait du transactionnel et la transaction doit obligatoirement se termine soit par un commit, soit un rollback.

C'est dans ce contexte précis que les question des verrous et accès concurrents se posent réellement.

On peut très bien faire du transactionnel sans créer des verrous. Pourquoi ?
Car selon le mode d'isolation que l'on utilise, le verrou se fait explicitement.
J'ai rappelé un peu plus bas dans ce sujet, les différents types de verrous et d'isolation que MySql propose.

La question des batchs me semble donc un peu hors sujet pour cette discussion.

Justement non et c'est une erreur classique dans le développement de ne pas savoir gérer le transactionnel dans un batch de nuit.
Il est nécessaire de placer des verrous pour être seul à faire du traitement de masse durant le batch de nuit.
Mais il faut aussi savoir gérer la journalisation !!!

Par ailleurs, les points de reprise existent dans MySQL, même s'ils ne font pas tout, j'en ai parlé précédemment, ils se gèrent au moyen de SAVEPOINT/ROLLBACK TO SAVEPOINT...

Je ne parlais pas de la sauvegarde d'un point de reprise, mais de sa gestion au sein d'un application.
A savoir quand vous faite une reprise applicative, vous devez redémarrer votre boucle à un rang particulier et non au debut de celle-ci.
De ce fait, dans une table destinée à gérer les points de reprise, vous devez spécifier le dernier identifiant qui a été validée.

Quand vous faites un traitement de masse qui dure disons quatre heures et qu'il plante à trois et demi, que faites-vous ?
Vous redémarrez depuis le début ? Ou bien à la dernière validation qui devient alors votre point de reprise ?

Si vous dites que vous n'utilisez pas les points de reprises, c'est que vous ne savez pas gérer applicativement un redémarrage suite à un plantage.

Je le répète, le mode transactionnel ne consiste pas uniquement à ouvrir une transaction et la terminer par un commit ou un rollback.
J'ai assez d'expérience dans ce domaine pour savoir de quoi je parle.

@+