Désactiver provisoirement l'autocommit

jhashe · 09/03/2011 18:42:35

Bonjour,

Pour un besoin particulier, j'aurais souhaité désactiver temporairement l'autocommit (à partir d'un projet en PHP).
Malheureusement, il n'est plus possible (depuis la version 7.4 je crois) d'envoyer un SET AUTOCOMMIT OFF.

Dans la documentation, je ne trouve que la possibilité de le désactiver globalement (via postgresql.conf) ou dans pgsql (de mémoire via \set autocommit off)

Existe-t-il une possibilité via SQL ?

Par avance, merci

SQLpro · 09/03/2011 18:43:09

Pourquoi ne pas tout simplement démarrer une transaction ????

a +

Marc Cousin · 09/03/2011 19:46:41

\set autocommit off, c'est une option de psql, l'outil en ligne de commande. Ça ne s'applique pas à php.

Vu qu'il n'y a pas l'air d'avoir de méthode pour démarrer une transaction dans les classes d'accès aux données PHP, il doit suffire d'exécuter un ordre SQL «BEGIN».

jhashe · 09/03/2011 22:15:52

C'était bien évidemment mon premier réflexe.

Malheureusement, ce n'est pas si simple que cela. En effet, mon interface est "Full Ajax" (basée sur la librairie extJS) et les différentes requêtes sont donc appelées via des scripts distincts, appelés de façon asynchrone. Or, visiblement, à la fin de chaque script, un COMMIT (en l'occurrence un AUTO-COMMIT donc) est réalisé.

Si j'appelle à la fermeture de ma pseudo-fenêtre (via un nouvel appel AJAX) un "simple" Rollback, rien ne se passe, puisque tout a déjà été commité (normal !)

D'où ma question: est-il possible de désactiver provisoirement l'autocommit ?

Etant donné le fruit de mes recherches, et les premières réponses fournies ici, je crains le pire...
Pourtant, cette fonctionnalité a existé par le passé, et je m'étonne de tomber sur une régression, aussi motivée soit-elle. PostgreSQL ne nous avait pas habitué à cela...

gleu · 09/03/2011 22:47:23

Pourtant, cette fonctionnalité a existé par le passé, et je m'étonne de tomber sur une régression, aussi motivée soit-elle.

PostgreSQL a toujours été et est encore en autocommit. À partir du moment où vous ne faites pas un BEGIN, l'instruction est immédiatement exécutée. Maintenant, vous avez peut-être une bibliothèque de fonctions qui faisaient automatiquement un BEGIN et qui ne le fait plus, mais il est clair que PostgreSQL n'a pas changé son comportement sur ce point là en tout cas.

SQLpro · 09/03/2011 22:51:33

Il est absolument stupide de vouloir faire une transaction dans une IHM en mode asynchrone (Ajax) !!! Voulez-vous que les tables soient verrouillées pendant tout le temps que les utilisateurs mettrons à discuter devant l'IHM, au point de bloquer tous les autres utilisateurs ??? Autant revenir à la manipulation de fichiers en Cobol !!!
Là c'est vous qui avez une problème de méthode et de choix des outils de développement...
Au passage lisez la diatribe que j'ai écrit sur les errements de développeurs face aux outils de, soit disant "haut niveau".... http://img1.lemondeinformatique.fr/fich … aisses.pdf

A +

Marc Cousin · 10/03/2011 02:12:56

SQLpro, pourrais tu avoir un minimum de politesse vis à vis des gens présents sur le forum ?

Démarrer une transaction en mode asynchrone n'est effectivement pas une bonne idée. Ce n'est pas une raison de qualifier cela de stupide. Les gens viennent pour recevoir de l'aide, pas pour se faire insulter.

jhashe · 10/03/2011 09:59:41

Bonjour,

J'ai de la chance, SQLPro connait mieux mon projet que moi, et la pertinence de ses réponses m'a aidé à résoudre mon problème :-))
(et ça tombe bien, je souhaite effectivement que les tables soient verrouillées; c'est exactement ce que je cherche à faire)

Et je suis quasiment sûr qu'il était possible de le faire via un "SET AUTOCOMMIT TO OFF" jusqu'aux version 7.3.x
(voir par exemple http://archives.postgresql.org/pgsql-ge … 00064.php)

Marc Cousin · 10/03/2011 12:32:54

Oui, maintenant (enfin «maintenant», la 7.4 commence à dater ), on ne peut plus faire cette commande, c'est totalement reporté dans la libpq (par exemple on peut demander à psql de ne pas être en autocommit).

En fait, côté serveur, on est en autocommit tant qu'on n'a pas envoyé BEGIN dans la session. Donc psql, par exemple, envoie un begin, dans le dos de l'utilisateur, quand on n'est pas en autocommit. C'est ce que fait aussi le driver JDBC par exemple… et, je présume, la plupart des autres drivers.

SQLpro · 11/03/2011 16:35:59

Marc Cousin a écrit :

SQLpro, pourrais tu avoir un minimum de politesse vis à vis des gens présents sur le forum ?

Je n'ai jamais été politiquement correct. Je ne le souhaite d'ailleurs pas, et ce n'est pas à mon âge que l'on va me faire changer de comportement. En revanche je n'ai jamais eu de propos diffamatoire ! Et permettez moi de vous faire remarquer que vous commettez une erreur...
En effet, je n'ai pas dit que jhashe était stupide ... Relisez SVP mes propos. J'ai simplement dit que cette idée était stupide. Même les meilleurs arrivent parfois à dire des bêtises. Par exemple Arago, qui était le plus brillant savant de son époque, à dit des chemins de fer (discours du 14 juin 1836) que les gens allaient s'asphyxier dans les tunnels, que les trépidations de la machine allaient leur décoller le cerveau et qu'ils allaient être atteint de strabisme à force de regardez la paysage défiler à la vitesse sidérante de 40 km/h...

Pour ma part, j'ai constaté que les conversations de salon était rarement entendu et que des propos virils, même et justement parce qu'ils suscitent des émotions, ont plus de force à pénétrer dans le subconscient des gens, et cela de la même manière que l'on apprend plus de ses échecs que de ses réussites !
Regardez autour de vous... Le gens s'intéressent plus à Sissi impératrice ou à Rambo le guerrier ?

Hier j'ai déjeuner avec Richard Stallman, le pape du logiciel libre.. J'ai été très intéressé par le violence de ses propos et par la férocité de son action... Pour lui, le libre est un combat et il a admis que s'il avait été là dans les années 50 avec de tels propos, il aurait probablement été chassé par Mc Carthy !

Enfin n'oubliez pas que les propos tenu dans un forum, bien que leur forme soit écrite, n'en relève pas moins de la langue parlé, car il faut aller vite à l'essentiel. Nous ne somme donc pas dans la rédaction d'article qui nécessite des heures ou des journées de synthèse et de peaufinement. nous somme dans le direct, l'urgence et l'essentiel... C'est pour cela que cet endroit s'appelle forum de discussion, or un discours, c'est bien de la langue parlé ! Et, pour rappel, tout ceux qui se sont amusé à censurer des propos jugés politiquement incorrects alors qu'il n'était en rien diffamant ont vu leur forum péricliter. C'est tout le problème de l'exercice de la démocratie !

Bref, accepter d'être critiqué, même violemment, est une preuve de bonne santé de notre système démocratique. Et croyez moi, je suis souvent critiqué sur mes propres écrits !!!

A +

SQLpro · 11/03/2011 16:37:32

jhashe a écrit :

je souhaite effectivement que les tables soient verrouillées; c'est exactement ce que je cherche à faire

Le problème est qu'il faut que vous soyez conscient que la montée en charge en sera fortement altérée avec des problématique de survenance de verrous mortels....

A +

gleu · 11/03/2011 17:26:04

J'ai simplement dit que cette idée était stupide.

Et ? la façon de le dire compte et c'était parfaitement déplacé. J'avoue que, comme Marc, j'ai été choqué par ce post. J'avais déjà constaté ce type de posts de votre part sur les forums de developpez.com et j'espérais que cela n'allait pas arriver ici. Apparemment, je me trompais. En tant qu'un des administrateur de ce forum, je tiens à ce qu'il y ait un minimum de correction et de politesse sur ce forum. Donc, dès maintenant, merci d'éviter les commentaires du type http://forums.postgresql.fr/viewtopic.p … 8372#p8372.

jhashe · 12/03/2011 10:54:22

SQLpro a écrit :

Le problème est qu'il faut que vous soyez conscient que la montée en charge en sera fortement altérée avec des problématique de survenance de verrous mortels....
A +

Il s'agit d'un back-office, dont l'accès de ne concerne que quelques personnes (j'ai plus de serveurs que d'utilisateurs dans ce cas ;-) ). La montée en charge est donc un problème qui ne se pose pas.

Par ailleurs, je me permets 2 petites remarques:
1- on ne choisit pas toujours ni son environnement de travail, ni son langage, ni son framework, surtout en entreprise.
2- un projet qui vit peut évoluer vers des directions non prévues initialement. Du coup, un choix judicieux à un instant donné peut, dans certaines circonstances, s'avérer partiellement ou totalement malheureux. Ce n'est pas pour autant (par exemple pour rajouter ue fonctionnalité), que l'on remet systématiquement par terre des années de développement. Tout ça pour dire que ces jugements péremptoires, s'ils peuvent être exacts en théorie, n'ont aucun sens face à des situations rélles qui sont toutes par définition des cas particuliers. Mais bon, je le sais, la mode est aux donneurs de leçons...

ioguix · 14/03/2011 15:38:40

Bonjour,

Il me semble que le problème original pourrait venir d'ailleurs: l'architecture elle même.

En effet, si vous utilisez une application PHP (avec de l'ajax ou non), il ne vous sera pas possible de créer et gérer des transactions à travers plusieurs appels coté serveur, que ce soit à avec modphp ou php-cgi.

Effectivement, dans le cas d'apache, entre 2 requêtes au serveur HTTP, même si vous conservez ouverte la connexion et la sessions entre votre httpd et PostgreSQL, rien ne dit qu'apache vous attribuera le même thread que pour votre requête HTTP précédente. La page suivante, issue de la documentation de PHP traite de ce sujet:

http://fr2.php.net/manual/fr/features.p … ctions.php

Une solution à votre problème serait donc d'utiliser les transactions préparées. Voir: http://docs.postgresql.fr/9.0/sql-prepa … ction.html

SQLpro · 14/03/2011 17:10:14

Sauf que les transactions préparées génère du COMMIT à deux phases, et rien ne garantit la bonne finalité des transactions. Pire, même, on peut se retrouver avec une transaction partiellement validée (et donc une autre partie annulée) sans savoir ce qui a été validé et ce qui a été annulé !

A +

Marc Cousin · 14/03/2011 18:21:17

On ne peut se trouver avec une transaction partiellement validée que si on fait plusieurs transactions avec le 2PC (transaction distribuée sur plusieurs bases par exemple). On se retrouve avec une transaction prête à être validée, par une autre session au besoin. Et c'est d'ailleurs la seule chose qu'on peut en faire : la valider ou l'annuler. Le problème, c'est que rien n'empêche cette transaction de rester en place pendant des mois.

On est donc d'accord, c'est loin d'être la panacée, puisqu'on peut se retrouver avec des transactions qui traînent pendant des mois si on ne prévoit pas un mécanisme pour les nettoyer. C'est aussi une des raisons pour lesquelles par défaut c'est désactivé… c'est bien trop dangereux, puisque pendant ce temps là, les transactions restent valides. Et on n'a donc pas de vacuum possible sur les tables de la base si ce genre de transactions traîne.

À mon avis, ça ne répond pas à la problématique, qui est de reprendre le travail sur la transaction, où il en était. Là, la seule chose qu'on puisse faire sur la connexion suivante, c'est valider ou non.

jhashe: Le mieux ça serait à mon avis de re-détailler le besoin, avec un exemple au besoin, j'ai l'impression qu'on s'éparpille un peu, là

jhashe · 14/03/2011 22:14:01

En fait, j'interviens sur un projet dont l'interface utilisateur est développée sous ExtJS (un framework Javascript offrant des widgets type "client lourd").
Dans ce projet, il est possible de modifier des tables d'une base PostgreSQL via une "pseudo-fenêtre modale" (je parle de "pseudo", car il ne s'agit d'une vraie fenêtre type popup de navigateur). Ce que j'aurais voulu, c'est que, si l'utilisateur ferme cette pseudo-fenêtre sans avoir cliqué sur le bouton Enregistrer, autrement dit, en cliquant soit sur la case de fermeture, soit sur le bouton Annuler, on retrouve l'état initial.

Beaucoup de widgets d'ExtJS fonctionnent via des appels asynchrones faciles à implémenter en liaison avec une base (par exemple, des treeviews, des grilles,...)

Alors, bien sûr, il est possible de réaliser ce que je souhaite, par exemple en dupliquant la structure à éditer dans un jeu de tables temporaires qui viendront écraser les anciennes données en cas d'enregistrement, mais c'est particulièrement lourd, étant donné le nombre de tables en jeu. Et ça reste "usine à gaz" alors que le mécanisme des transactions, que j'utilise fréquemment dans des scripts "classiques" fonctionne à merveille et réponds totalement à mes besoins.

Ce que je n'avais pas prévu, c'est que, bien qu'étant dans une opération unitaire et modale en terme d'interface utilisateur, ça reste de l'asynchrone en terme d'architecture. Ce qui n'aurait posé aucun problème dans un environnement "client lourd" classique, devient donc problématique dans ce "bureau web"

Je suis désolé de ne pas pouvoir envoyer de lien pour illustrer mes propos, mais il s'agit d'un intranet privé.
Et j'espère surtout avoir été à peu près clair.

Encore merci à tous ceux qui ont pris la peine de me répondre.

Marc Cousin · 14/03/2011 22:26:38

Je vais peut-être me faire l'avocat du diable, mais et utiliser postgres.js, si ce n'est pas le cas ? (driver postgres pur javascript)

Et donc attaquer la base en direct… au lieu de passer par le serveur web et rencontrer toutes les problématiques citées juste au dessus ?

SQLpro · 17/03/2011 19:05:58

Et oui, toujours l'utilisation de framework et d'ORM de plus en plus catastrophique pour les performances, alors que le développement natif est bien plus simple dans le SBDR directement via des proc stock des vues etc... Chose que je dénonce depuis des années : http://img1.lemondeinformatique.fr/fich … aisses.pdf

A +

Marc Cousin · 17/03/2011 21:32:29

Tout à fait d'accord. Mais ce n'est pas la question

#1 09/03/2011 18:42:35

Désactiver provisoirement l'autocommit

#2 09/03/2011 18:43:09

Re : Désactiver provisoirement l'autocommit

#3 09/03/2011 19:46:41

Re : Désactiver provisoirement l'autocommit

#4 09/03/2011 22:15:52

Re : Désactiver provisoirement l'autocommit

#5 09/03/2011 22:47:23

Re : Désactiver provisoirement l'autocommit

#6 09/03/2011 22:51:33

Re : Désactiver provisoirement l'autocommit

#7 10/03/2011 02:12:56

Re : Désactiver provisoirement l'autocommit

#8 10/03/2011 09:59:41

Re : Désactiver provisoirement l'autocommit

#9 10/03/2011 12:32:54

Re : Désactiver provisoirement l'autocommit

#10 11/03/2011 16:35:59

Re : Désactiver provisoirement l'autocommit

#11 11/03/2011 16:37:32

Re : Désactiver provisoirement l'autocommit

#12 11/03/2011 17:26:04

Re : Désactiver provisoirement l'autocommit

#13 12/03/2011 10:54:22

Re : Désactiver provisoirement l'autocommit

#14 14/03/2011 15:38:40

Re : Désactiver provisoirement l'autocommit

#15 14/03/2011 17:10:14

Re : Désactiver provisoirement l'autocommit

#16 14/03/2011 18:21:17

Re : Désactiver provisoirement l'autocommit

#17 14/03/2011 22:14:01

Re : Désactiver provisoirement l'autocommit

#18 14/03/2011 22:26:38

Re : Désactiver provisoirement l'autocommit

#19 17/03/2011 19:05:58

Re : Désactiver provisoirement l'autocommit

#20 17/03/2011 21:32:29

Re : Désactiver provisoirement l'autocommit

Pied de page des forums

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux