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 ?

tof et jte repond

poste ta réponse pendant que j'en scanne une

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 )

Question con : celui qui est bloqué essaie pas d'écrire une ligne ayant une clé identique à une déjà écrite par l'autre?

 
ah bin ca pour etre con, c'etait con

handicapé du clavier...

Postgre cay nul, installes Oracle
 
(edit: reponse special dedicace a mareek )

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)

bah si tu veux, quand on utilise pgaccess, ou psql, on n'a pas ce genre de problèmes...

 
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

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

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

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

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)

...et vous avez pas mis des restrictions à la con sans le faire exprès ailleurs?

http://ccm.redhat.com/bboard-archive/webdb/0007Ax.html
 

 
kessekeca ?

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

Bon, ben tout s'explique, non...

comprend rien
une idée de solution?

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

DNC
on va prendre la solution "multirequêtes"

S'ils le disent je les crois...
 
[edit]
 

 
ca explique rien, bordel, reste la question : pourquoi ?

parce-que c'ets un sgbd pourri...oracle roxxxxxxxxe!

rah mais merde, meme avec un bete insert (sans sous requete select) ca debloque

rah mais merde 2 : ca bloque que si on ecrit dans un champ particulier (??)

Et il a quoi de particulier?

On sait pas a vu de nez c'est un int, on a un enqueteur qui se penche sur le probleme

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

integrité référentielle sur une autre table

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

 
!
je ne savais pas que tu avais autant de gout !

 
Excellentes questions...
C'est pas moi l'expert en bases de données ici...demandez à Harko (:whistle ou gizmo, nan?
 

Tu devrais...

 
sont pas la ou ils me boudent
 

 
(jles ai vu en concert vendredi dernier )

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?