Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Applications Applications SGBD [postgres] transactions concurentes...

[postgres] transactions concurentes...

7 réponses
Avatar
MaXX
Bonjour,
Je me fais la main sur postgres, et je ne parviens pas à piger comment
postgres "fait" pour garder ses tables bien propre malgré des transactions
simultanées. Les bases qui verouillent les table pendant les transactions
sont plus "simples" à comprendre.
Je dois être très con ou passer à côté des choses simples, mais je me pose
quand même la question...

un utilisateur A lance un gros bloc transactionnel sur une base genre:
BEGIN
[faire plein de trucs qui prennent du temps select avec
jointures,update sur des tables monstrueuses,... le tout bien imbriqué
et dépendant des valeurs retournées par la commande précédante]
COMMIT

Pendant que la base se depatouille avec les requètes de A, l'utilisateur B
supprime un des enregistrement utilisés dans le bloc de A (la fenêtre de
temps est courte, mais ça se passe pile poil au mauvais moment).

Comment diable fait postmaster pour finir le bloc de A?
-Il a conservé une "copie" des tables par des row version ou qqch du genre
et il continue avec la copie et retourne un joli OK à l'utilisateur A? Ca
pourait avoir des conséquences fâcheuses dans certains cas...

-il manque une donnée pour repondre ok et il retourne une erreur comme si la
donnée n'avait jamais existé?

-la ligne a été verrouillée et c'est B qui reçoit l'erreur?

-il recrée l'enregistrement sur base des resulats de la transaction de A?

-je ferais mieux de ne pas me poser la question et regarder la boite magique
fonctionner toute seule?

Plus j'y pense et plus je suis dans le flou...
Des sources d'éclairages? En tout cas chapeau bas aux mecs qui ont conçu le
système...

Merci

MaXX
Signaler un problème avec ce contenu

7 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Patrick Mevzek
Le Wed, 02 Feb 2005 19:28:55 +0100, MaXX a écrit :
Comment diable fait postmaster pour finir le bloc de A?
-Il a conservé
une "copie" des tables par des row version ou qqch du genre et il
continue avec la copie et retourne un joli OK à l'utilisateur A?



Oui c'est comme ca que fonctionne PostgreSQL, ca s'appelle le MVCC, et je
crois que Oracle fait pareil.

Ca pourait avoir des conséquences fâcheuses dans certains cas...



Le standard SQL prévoit 4 niveaux d'isolation entre les transactions.
PostgreSQL en support 2, et ca semble suffisant.

Plus j'y pense et plus je suis dans le flou... Des sources d'éclairages?



Quelques pistes googliennes en anglais:
http://www.linuxgazette.com/issue68/mitchell.html
http://www.netcraft.com.au/geoffrey/postgresql/mvcc.html
http://www.onlamp.com/pub/a/onlamp/2001/05/25/postgresql_mvcc.html

Et chez PostgreSQL directement:
http://www.postgresql.org/docs/8.0/static/mvcc.html

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Avatar
MaXX
Patrick Mevzek wrote:

Quelques pistes googliennes en anglais:
http://www.linuxgazette.com/issue68/mitchell.html
http://www.netcraft.com.au/geoffrey/postgresql/mvcc.html
http://www.onlamp.com/pub/a/onlamp/2001/05/25/postgresql_mvcc.html

Et chez PostgreSQL directement:
http://www.postgresql.org/docs/8.0/static/mvcc.html



Merci, j'ai trouvé une bonne explication dans les docs de postgres.
Je suis inexcusable! Hier, j'ai directement sauté au chapitre
administration/sauvegarde, faisant fi des notions de base!

Encore Merci

MaXX
Avatar
Fred BROUARD - SQLpro
bonjour,

tout dépend du niveau d'isolation des transactions.
De plus, toutes les transactions sont journalisées.

Pour comprendre les mécanismes mis en jeu dans les SGBDR client/serveur je
t'invite à lire les articles que j'ai écrit sur le sujet :
1) Transactions : http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1
2) Journalisation : http://sqlpro.developpez.com/cours/sqlaz/techniques/#L8


A +

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************


MaXX a écrit:
Bonjour,
Je me fais la main sur postgres, et je ne parviens pas à piger comment
postgres "fait" pour garder ses tables bien propre malgré des transactions
simultanées. Les bases qui verouillent les table pendant les transactions
sont plus "simples" à comprendre.
Je dois être très con ou passer à côté des choses simples, mais je me pose
quand même la question...

un utilisateur A lance un gros bloc transactionnel sur une base genre:
BEGIN
[faire plein de trucs qui prennent du temps select avec
jointures,update sur des tables monstrueuses,... le tout bien imbriqué
et dépendant des valeurs retournées par la commande précédante]
COMMIT

Pendant que la base se depatouille avec les requètes de A, l'utilisateur B
supprime un des enregistrement utilisés dans le bloc de A (la fenêtre de
temps est courte, mais ça se passe pile poil au mauvais moment).

Comment diable fait postmaster pour finir le bloc de A?
-Il a conservé une "copie" des tables par des row version ou qqch du genre
et il continue avec la copie et retourne un joli OK à l'utilisateur A? Ca
pourait avoir des conséquences fâcheuses dans certains cas...

-il manque une donnée pour repondre ok et il retourne une erreur comme si la
donnée n'avait jamais existé?

-la ligne a été verrouillée et c'est B qui reçoit l'erreur?

-il recrée l'enregistrement sur base des resulats de la transaction de A?

-je ferais mieux de ne pas me poser la question et regarder la boite magique
fonctionner toute seule?

Plus j'y pense et plus je suis dans le flou...
Des sources d'éclairages? En tout cas chapeau bas aux mecs qui ont conçu le
système...

Merci

MaXX
Avatar
MaXX
Fred BROUARD - SQLpro wrote:
bonjour,
Pour comprendre les mécanismes mis en jeu dans les SGBDR client/serveur je
t'invite à lire les articles que j'ai écrit sur le sujet :
1) Transactions : http://sqlpro.developpez.com/cours/sqlaz/techniques/#L1
2) Journalisation :
http://sqlpro.developpez.com/cours/sqlaz/techniques/#L8

A +


Super, j'avais déjà une bonne idée par les liens de Patrick Mevzek, et là je
crois que c'est bon; les exemples aident bien à saisir le "pourquoi ça
marche" ou pas...

Maintenant, je vais réécrire certaines de mes table, j'utilise une syntaxe
un peu trop perso pour les noms de tables et autres...

Pour la journalisation, je pense que je vais l'utiliser dans peu de temps,
pour l'instant elle est active mais je ne comprenais pas vraiment à quoi
servaient ces fichiers... Approfondir!

Encore merci,
je vais m'atteler à des taches plus manuelles (ménage) puis je retourne à
ces intéressantes lectures...

MaXX
Avatar
see
Fred BROUARD - SQLpro wrote:

2) Journalisation : http://sqlpro.developpez.com/cours/sqlaz/techniques/#L8



Soit j'ai mal compris ce tu as écris, soit Oracle a un comportement très
particulier, soit il y a une erreur.

Je me base sur le fonctionnement de Oracle (sans entrer dans les détails
de l'implémentation). Il semble que PostGres se soit inspiré du
fonctionnement de Oracle.

Tu écris :
"Le SGBDR signale au client que la requête a été prise en compte et lui
demande d'attendre le retour d'exécution."

Cette phrase résume mon désaccord.
1- Je n'ai jamais vu cette phase intermédiaire où le SGBDR signale que
la requête a été prise en compte.

2- le SGBDR reçoit les requêtes les une après les autres. Il ne connait
généralement pas (et n'a donc pas eu la possibilité de la stocker) la
transaction dans son ensemble avant de recevoir la commande commit.
Si une coupure de courant se produit avant de recevoir le commit, le
SGBDR est dans l'incapacité de terminer une transaction qu'il ne connait
pas !
Je ne pense pas que la transaction soit dans une procédure stockée
change quoi que ce soit.

3- le SGBDR ne redémarre pas "le travail sur les transactions
inachevées" lors d'une reprise.

Une transaction qui a été validée est définitive. Le sgbdr assure,
lorsqu'il rend la main à l'utilisateur, que le commit est définitif.
Une transaction qui n'a pas été validée est annulée lors de la reprise

Donc je ne comprends pas ce que tu veux dire quand tu écris :
"et recommence son travail."
Le SGBDR ne recommence rien du tout. Une transaction qui n'a pas été
validée devra être relancer !

--
Bruno
http://errance.lirano.net
Avatar
Michel Bernard
Bruno Jargot wrote:

Tu écris :
"Le SGBDR signale au client que la requête a été prise en compte et lui
demande d'attendre le retour d'exécution."

Cette phrase résume mon désaccord.
1- Je n'ai jamais vu cette phase intermédiaire où le SGBDR signale que
la requête a été prise en compte.




C'est bien entendu caché à l'utilisateur.

2- le SGBDR reçoit les requêtes les une après les autres. Il ne connait
généralement pas (et n'a donc pas eu la possibilité de la stocker) la
transaction dans son ensemble avant de recevoir la commande commit.
Si une coupure de courant se produit avant de recevoir le commit, le
SGBDR est dans l'incapacité de terminer une transaction qu'il ne connait
pas !
Je ne pense pas que la transaction soit dans une procédure stockée
change quoi que ce soit.



qui te parle de procédure stockée ?




--
Michel Bernard
http://www.giromini.org/usenet-fr/repondre.html
Avatar
see
Michel Bernard wrote:

Bruno Jargot wrote:

> Tu écris :
> "Le SGBDR signale au client que la requête a été prise en compte et lui
> demande d'attendre le retour d'exécution."
>
> Cette phrase résume mon désaccord.
> 1- Je n'ai jamais vu cette phase intermédiaire où le SGBDR signale que
> la requête a été prise en compte.
>

C'est bien entendu caché à l'utilisateur.



OK. Mais je ne vois alors pas trop l'intérêt d'en parler.


> 2- le SGBDR reçoit les requêtes les une après les autres. Il ne connait
> généralement pas (et n'a donc pas eu la possibilité de la stocker) la
> transaction dans son ensemble avant de recevoir la commande commit.
> Si une coupure de courant se produit avant de recevoir le commit, le
> SGBDR est dans l'incapacité de terminer une transaction qu'il ne connait
> pas !
> Je ne pense pas que la transaction soit dans une procédure stockée
> change quoi que ce soit.

qui te parle de procédure stockée ?



J'essayais d'anticiper les objections possibles à ma remarque. Tu peux
ignorer la phrase.


--
Bruno
http://errance.lirano.net