Vous n'êtes pas identifié(e).
Bonsoir,
Alors là, je suis pantois devant ceci :
[15074] 2011-06-29 23:29:17 CEST 4/88492009 0 LOG: instruction : begin transaction
[15074] 2011-06-29 23:29:17 CEST 4/88492009 0 LOG: exécute <unnamed>: select count_application_hit from application_hit where id_account_application_hit = $1 and appfm_application_hit = $2 and appver_application_hit = $3 and appname_application_hit = $4 for update
[15074] 2011-06-29 23:29:17 CEST 4/88492009 0 DÃTAIL: paramètres : $1 = '105739', $2 = 'ios', $3 = '305', $4 = 'NomAppli'
[15074] 2011-06-29 23:29:17 CEST 4/88492009 0 LOG: exécute <unnamed>: insert into application_hit ( id_account_application_hit , apppfm_application_hit , appver_applcation_hit , appname_application_hit , count_application_hit ) values ( $1 , $2 , $3 , $4 , $5 )
[15074] 2011-06-29 23:29:17 CEST 4/88492009 0 DÃTAIL: paramètres : $1 = '105739', $2 = 'ios', $3 = '305', $4 = 'NomAppli', $5 = '1'
[15074] 2011-06-29 23:29:17 CEST 4/88492009 124647794 LOG: instruction : commit
[15075] 2011-06-29 23:29:17 CEST 5/53691771 0 LOG: instruction : begin transaction
[15075] 2011-06-29 23:29:17 CEST 5/53691771 0 LOG: exécute <unnamed>: select count_application_hit from application_hit where id_account_application_hit = $1 and appfm_application_hit = $2 and appver_application_hit = $3 and appname_application_hit = $4 for update
[15075] 2011-06-29 23:29:17 CEST 5/53691771 0 DÃTAIL: paramètres : $1 = '105739', $2 = 'ios', $3 = '305', $4 = 'NomAppli'
[15075] 2011-06-29 23:29:17 CEST 5/53691771 0 LOG: exécute <unnamed>: insert into application_hit ( id_account_application_hit , apppfm_application_hit , appver_applcation_hit , appname_application_hit , count_application_hit ) values ( $1 , $2 , $3 , $4 , $5 )
[15075] 2011-06-29 23:29:17 CEST 5/53691771 0 DÃTAIL: paramètres : $1 = '105739', $2 = 'ios', $3 = '305', $4 = 'NomAppli', $5 = '1'
[15075] 2011-06-29 23:29:17 CEST 5/53691771 124647795 ERREUR: la valeur d'une clé dupliquée rompt la contrainte unique « application_hit_pkey »
[15075] 2011-06-29 23:29:17 CEST 5/53691771 124647795 INSTRUCTION : insert into application_hit ( id_account_application_hit , apppfm_application_hit , appver_application_hit , appname_application_hit , count_application_hit ) values ( $1 , $2 , $3 , $4 , $5 )
En clair : j'ouvre une transaction(4/88492009), je regarde si j'ai une ligne contenant (105739,ios,305,NomAppli), et comme elle n'existe pas, je l'insère et commite la transaction. Un pouième plus tard, une nouvelle requete se pointe via une autre transaction (5/53691771), refait le select et bam!, postgres semble ne pas avoir trouvé la ligne commitée précedemment. Là j'avoue ne pas comprendre. Le fait de la commiter ne la rend pas visible aux futures transactions ?
Pour etre exhaustif, voici le code ECPG que j'utilise :
EXEC SQL SELECT count_application_hit
INTO :pg_count
FROM application_hit
WHERE id_account_application_hit = :pg_id_account
AND apppfm_application_hit = :pg_apppfm
AND appver_application_hit = :pg_appver
AND appname_application_hit = :pg_appname
FOR UPDATE ;
if ( sqlca.sqlcode == ECPG_NOT_FOUND ) {
EXEC SQL INSERT INTO application_hit ( id_account_application_hit , apppfm_application_hit , appver_application_hit , appname_application_hit , count_application_hit )
VALUES ( :pg_id_account , :pg_apppfm , :pg_appver , :pg_appname , :pg_count );
if ( sqlca.sqlcode != ECPG_NO_ERROR ) {
return ( sqlca.sqlcode );
}
}
else {
EXEC SQL UPDATE application_hit
SET count_application_hit = count_application_hit + 1
WHERE id_account_application_hit = :pg_id_account
AND apppfm_application_hit = :pg_apppfm
AND appver_application_hit = :pg_appver
AND appname_application_hit = :pg_appname;
if ( sqlca.sqlcode != ECPG_NO_ERROR ) {
return ( sqlca.sqlcode );
}
}
(d'ailleurs à me relire je pourrais tester que le SELECT s'est passé sans erreur avant de faire l'UPDATE...).
Merci de vos lumières !
SCO
Hors ligne
Le fait de la commiter ne la rend pas visible aux futures transactions ?
Si. Le problème doit provenir de votre outil.
Guillaume.
Hors ligne
Ce qui me tracasse c'est le log postgresql, il n'y a vraiment rien qui puisse expliquer ce comportement !
Hors ligne
Ils sont tous à la même seconde, difficile de dire dans quel ordre tout ça s'est fait.
Guillaume.
Hors ligne
Je vois .. si effectivement en lisant la séquence BEGIN/COMMIT/BEGIN/COMMIT on peut envisager que la séquence réelle était BEGIN/BEGIN/COMMIT/COMMIT ca change tout ! Dommage que l'ordre ne soit pas fiable...
Je vais essayer ceci : http://www.postgresql.org/docs/current/ … RT-EXAMPLE, plutôt confiant !
Merci Guillaume !
Hors ligne