aidez une pauvre etudiante avec une requete bloquante - SQL/NoSQL - Programmation
Marsh Posté le 03-12-2004 à 10:35:30
poste ta réponse pendant que j'en scanne une
Marsh Posté le 03-12-2004 à 10:41:14
j'ajouterais-je aussi: est-ce que cela peu-il venir du multi-threading?
(j'ai oublié de préciser que je suis SA binôme et que moi j'ai des petits seins mais c'est pas grave )
Marsh Posté le 03-12-2004 à 10:46:48
Question con : celui qui est bloqué essaie pas d'écrire une ligne ayant une clé identique à une déjà écrite par l'autre?
Marsh Posté le 03-12-2004 à 10:47:07
skeye a écrit : Question con : |
ah bin ca pour etre con, c'etait con
Marsh Posté le 03-12-2004 à 10:47:27
chrisbk a écrit : ah bin ca pour etre con, c'etait con |
handicapé du clavier...
Marsh Posté le 03-12-2004 à 10:48:10
Postgre cay nul, installes Oracle
(edit: reponse special dedicace a mareek )
Marsh Posté le 03-12-2004 à 10:48:15
Hummm ta base accepte-t-elle d'avoir plusieurs transactions simultanées sur une même table ?
(je dis ça comme ça, le sujet m'intéresse aussi)
Marsh Posté le 03-12-2004 à 10:49:41
Fred999 a écrit : Hummm ta base accepte-t-elle d'avoir plusieurs transactions simultanées sur une même table ? |
bah si tu veux, quand on utilise pgaccess, ou psql, on n'a pas ce genre de problèmes...
Marsh Posté le 03-12-2004 à 10:50:29
Fred999 a écrit : Hummm ta base accepte-t-elle d'avoir plusieurs transactions simultanées sur une même table ? |
On vient de se rendre compte que quand on le fait 'a la main' (en utilisant psql) on etait pas bloqué (??)
Cela viendrait-il d'une mauvaise utilisation de l'api psql ? Etant donnée qu'on est blonde toute les deux on a un peu de mal
skeye : non je pense pas, mais jverifie quand meme
Marsh Posté le 03-12-2004 à 10:55:03
skeye a écrit : Question con : celui qui est bloqué essaie pas d'écrire une ligne ayant une clé identique à une déjà écrite par l'autre? |
la clé est un incrément auto
et j'ai vérifié, même si on bosse avec des sessions différentes (BEGIN,END) on n'a jamais le même ident
Marsh Posté le 03-12-2004 à 11:02:28
humm et un incrément auto il se passe quoi si le premier qui insère fait un rollback après que le second ait inséré? On perd un indice?
Marsh Posté le 03-12-2004 à 11:07:34
skeye a écrit : humm et un incrément auto il se passe quoi si le premier qui insère fait un rollback après que le second ait inséré? On perd un indice? |
oui
Marsh Posté le 03-12-2004 à 11:07:53
Ok, du neuf.
si on lance deux psql :
on fait 'begin' dans les deux
dans le premier on fait un insert dans un table, et cet insert contient une sous requete sql
dans le deuxieme on effectue le meme insert
=>blocquage du deuxieme jusque ce que le premier fasse un commit ou un rollback
créfieu
Marsh Posté le 03-12-2004 à 11:10:18
chrisbk a écrit : Ok, du neuf. |
humm mais c'est autorisé d'avoir 2 fois le même enregistrements dans ta table?
Marsh Posté le 03-12-2004 à 11:10:53
skeye a écrit : humm mais c'est autorisé d'avoir 2 fois le même enregistrements dans ta table? |
bah non, on aura 2 ID différents (incrément auto)
Marsh Posté le 03-12-2004 à 11:11:36
moktar1er a écrit : bah non, on aura 2 ID différents (incrément auto) |
...et vous avez pas mis des restrictions à la con sans le faire exprès ailleurs?
Marsh Posté le 03-12-2004 à 11:12:41
http://ccm.redhat.com/bboard-archive/webdb/0007Ax.html
Citation : In Postgres, a select for update will acquire exclusive row locks on the selected rows. In your example, this would cause user 1 to block user 2 until the transaction is commited (select for update is only legal within an explicit transaction in Postgres). In your example, where you're selecting from within an insert query, the insert will gain the exclusive row locks on the selected rows automatically and if you're not within an explicit transaction will be committed before the locks are released. |
kessekeca ?
Marsh Posté le 03-12-2004 à 11:13:37
vous avez essayé, au fait?
Parce-qu'intuitivement j'aurais pensé que le 2ème bloquait parce-qu'on refusait de lui filer un auto-incrémenté...
Marsh Posté le 03-12-2004 à 11:14:34
chrisbk a écrit : http://ccm.redhat.com/bboard-archive/webdb/0007Ax.html
|
Bon, ben tout s'explique, non...
Marsh Posté le 03-12-2004 à 11:17:17
ReplyMarsh Posté le 03-12-2004 à 11:17:57
moktar1er a écrit : comprend rien |
faire la sous-requête avant et utiliser le résultat pour faire un insert sans sous-requête?
Marsh Posté le 03-12-2004 à 11:22:26
skeye a écrit : faire la sous-requête avant et utiliser le résultat pour faire un insert sans sous-requête? |
ouais... ça va un peu alourdir le bousin mais why not...
sinon sur le site là ils disent qu'il faut faire un
SELECT FOR UPDATE
au lieu d'un SELECT tout court...
ma binôme aux gros seins est en train d'essayer
Marsh Posté le 03-12-2004 à 11:23:29
|
DNC
on va prendre la solution "multirequêtes"
Marsh Posté le 03-12-2004 à 11:23:40
S'ils le disent je les crois...
[edit]
Marsh Posté le 03-12-2004 à 11:35:40
skeye a écrit : Bon, ben tout s'explique, non... |
ca explique rien, bordel, reste la question : pourquoi ?
Marsh Posté le 03-12-2004 à 11:36:18
chrisbk a écrit : ca explique rien, bordel, reste la question : pourquoi ? |
parce-que c'ets un sgbd pourri...oracle roxxxxxxxxe!
Marsh Posté le 03-12-2004 à 11:57:43
rah mais merde, meme avec un bete insert (sans sous requete select) ca debloque
Marsh Posté le 03-12-2004 à 11:59:28
chrisbk a écrit : rah mais merde, meme avec un bete insert (sans sous requete select) ca debloque |
skeye a écrit : vous avez essayé, au fait? |
Marsh Posté le 03-12-2004 à 11:59:30
rah mais merde 2 : ca bloque que si on ecrit dans un champ particulier (??)
Marsh Posté le 03-12-2004 à 12:00:02
Et il a quoi de particulier?
Marsh Posté le 03-12-2004 à 12:00:31
On sait pas a vu de nez c'est un int, on a un enqueteur qui se penche sur le probleme
Marsh Posté le 03-12-2004 à 12:02:21
y'a des contraintes d'intégrité d'sus (fo que la valeur donnée soit presente dans une autre table (ce qui est vrai au moment le l'insert))
Marsh Posté le 03-12-2004 à 12:05:01
...et ça lockerait pas l'autre table en exclusif de faire un insert là-dessus, au hasard?
Marsh Posté le 03-12-2004 à 12:06:17
skeye a écrit : ...et ça lockerait pas l'autre table en exclusif de faire un insert là-dessus, au hasard? |
heuh, bin, visiblement, hein, oui, mais :
->pourquoi
->comment circonvenir a cet astucieux lock de merde ?
Citation : Dolly - [Plein Air #13] - Tim |
!
je ne savais pas que tu avais autant de gout !
Marsh Posté le 03-12-2004 à 12:08:43
chrisbk a écrit : heuh, bin, visiblement, hein, oui, mais : |
Excellentes questions...
C'est pas moi l'expert en bases de données ici...demandez à Harko (:whistle ou gizmo, nan?
chrisbk a écrit :
|
Tu devrais...
Marsh Posté le 03-12-2004 à 12:09:51
skeye a écrit : Excellentes questions... |
sont pas la ou ils me boudent
skeye a écrit : |
(jles ai vu en concert vendredi dernier )
Marsh Posté le 03-12-2004 à 12:11:35
Histoire d'avancer un peu, z'avez essayé de faire un select sur l'autre table avant le commit pour vérifier que c'était bien cette table qui lockait?
Marsh Posté le 03-12-2004 à 10:29:00
bonjour
je suis une jeune etudiante célibataire avec des gros seins et j'ai un probleme
J'ai un gros programme A qui se connecte a une BD Postgres. Au debut il fait un "BEGIN", apres des insert, des selects, des trucs et des machins et d'autres traitements super, termine par un "COMMIT" et meurt heureux, sa tache accomplie.
Si avant qu'il finisse son traitement (qui peuvent durer un certain temps), on lance un autre 'A' (qui va donc effectuer la meme serie d'actions, connect, begin, toussa), cet 'A' va etre mis en attente au niveau d'un INSERT dans la base. C'est vachement chiant et je suis toute dépitée
D'ouske ca peut venir ?
Message édité par chrisbk le 03-12-2004 à 10:30:10
---------------
NP: HTTP Error 764 Stupid coder found