Discussion :

[dubitoph]

Bonjour,

J'ai déjà exposé mon problème dans le forum "MySql", mais je ne suis pas certain que le problème que je rencontre ne provienne pas de Php.

Dans une application pour call center, je traite une série de "suivis" qui, lors de leur traitement, permettent une composition automatique du numéro de téléphone.

Afin que deux employés du call center ne traitent pas en même temps un même suivi, dans ma table "suivis", j'ai un champ "occupe" qui est à 1 lorqu'il est en cours de traitement, sinon à 0.

Donc, dans mes requêtes de sélection du suivi à traiter au moment dit par l'employé, je ne sélectionne qu'un suivi dont le champ "occupe" est à 0. Voici, ci-après, une de mes requêtes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select cibles.* from cibles, suivis where refCampagne = " . $param[0] . " and cibles.id = refCible and !cloture and rappelPrior = 1 and (dateRappel > date_sub(curdate(), interval 1 day) and dateRappel < date_sub(now(), interval 15 minute)) and !occupe order by dateRappel desc limit 1

Le problème est qu'en production, il arrive que des employés travaillent en même temps sur le même suivi, alors que mon champ "occupe" est bien updaté à 1 dès qu'un employé travaille dessus. Ce qui m'étonne d'autant plus, c'est que lorsque je fais le test via PhpMyAdmin, ma requête ne me ramène pas les suivis occupés, tandis que, via l'application, en ouvrant deux instances de FireFox, je reproduis à chaque fois le phénomène.

Voici deux informations supplémentaires. Dans ma requête, j'ai utilisé "SQL_NO_CACHE", mais cela n'a rien changé. Deuxièmement, j'utilise, pour tous les utilisateurs de l'application, une seule connection persistante à la base de données.

Voici les différentes portions de codes utiles :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
$retour = $objCampagne->chargerCible($tabVendPrior);

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public function chargerCible($tabVendeurs)
   {
    if(get_magic_quotes_gpc()) //test si les magic_quotes sont activées
     $objUtilisateur = unserialize(stripslashes($_COOKIE['utilisateur']));
    else
     $objUtilisateur = unserialize($_COOKIE['utilisateur']);
 
    $tab[0] = $this->id;
    $tab[1] = $objUtilisateur->getId();
 
    if(!empty($tabVendeurs))
     $tab = array_merge($tab, $tabVendeurs);
 
    $transaction = CtransactionsBdd::GetInstance("MYSQL", "speedcall");
    $resuReq = $transaction->select("MYSQL_chargerCibleLapsTempsEnCoursPrior", $tab); // On charge une cible dont la date de rappel indiquée par l'utilisateur se situe dans le laps de temps +- 15 minutes par rapport à l'heure actuelle
 
    if ($transaction->getErreur() == "Aucun résultat")
     {
      $resuReq2 = $transaction->select("MYSQL_chargerCibleRappelDateJourPrior", $tab); // On charge une cible dont la date de rappel indiquée par l'utilisateur est celle du jour
 
      if(!count($resuReq2[0]))
...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
case "MYSQL_chargerCibleRappelDateJourPrior":
         return "select SQL_NO_CACHE cibles.* from cibles, suivis where refCampagne = " . $param[0] . " and cibles.id = refCible and !cloture and rappelPrior = 1 and (dateRappel > date_sub(curdate(), interval 1 day) and dateRappel < date_sub(now(), interval 15 minute)) and !occupe order by dateRappel desc limit 1";
        break;

Une dernière chose très étonante, afin de tracer au mieux les requêtes exécutées, j'ai voulu les écrire dans un fichier texte via ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
case "MYSQL_chargerCibleRappelDateJourPrior":
        $Fnm = "../rappReq.txt";
        $inF = fopen($Fnm,"w");
        $texte = "select SQL_NO_CACHE cibles.* from cibles, suivis where refCampagne = " . $param[0] . " and cibles.id = refCible and !cloture and rappelPrior = 1 and (dateRappel > date_sub(curdate(), interval 1 day) and dateRappel < date_sub(now(), interval 15 minute)) and !occupe order by dateRappel desc limit 1"; 
        fwrite($inF,$texte."\n");
        fclose($inF);
        return "select SQL_NO_CACHE cibles.* from cibles, suivis where refCampagne = " . $param[0] . " and cibles.id = refCible and !cloture and rappelPrior = 1 and (dateRappel > date_sub(curdate(), interval 1 day) and dateRappel < date_sub(now(), interval 15 minute)) and !occupe order by dateRappel desc limit 1";
        break;

Lors de la première exécution, je retrouve bien la requête dans le fichier texte. Par contre je n'y retrouve aucune trace d'une autre requête, alors que les deux mêmes fiches client sont affichées à l'écran.

Quelqu'un aurait une idée?

Merci d'avance pour toute piste que vous pourriez m'indiquer.

[gene69]

le SQL_NO_CACHE était effectivement inutile.

Si j'ai bien compris tu as un drapeau pour dire qu'une ligne (correspondant à un traitement) était en cours de traitement . Et que tu te retrouves avec deux personnes qui prennent le même drapeau en même temps. Et ça dans un FPS ou dans un SGBD c'est mal vu.

sans avoir regardé ton code ni la discutions dans le forum mysql, je vais te dire c'est un cas improbable d'une lecture concurrente et la mise à jour en fonction de la lecture qui ne se fait pas de façon atomique.

Tu dois d'une façon ou d'une autre avoir un bout de code qui dit

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Selection du traitement ou drapeau = baissé
Mise a jour traitement, drapeau = levé quand il s'agit du traitement X.

Il faudrait que tu testes le affected_row() de la mise à jour, renvoyer une exception si c'est différent de 1.

Je va lire ton code. Tu utilises un framework connu?

[gene69]

en fait pour etre plus exlicite du point de vue sql, j'ai oublié une condition:

UPDATE traitement SET drapeau = "levé" WHERE drapeau = "baissé" AND traitement = "X"

[RunCodePhp]

Salut

Je suis très très loin d'avoir tout vu en SQL, mais ce qui me saute yeux c'est ceci : !cloture, et à plusieurs reprise.
Comme le dysfonction à l'air lié à ce champ, je me dis qu'il faudrait confirmer certains points.

En 1er, cette syntaxe m'est inconnue en SQL, j'aurais plus vu quelque chose comme : AND cloture = 1 ou cloture > 0

Mais comme ça à l'air de ne pas générer d'erreur SQL (encore que faudrait peut être vérifier les logs), donc en admettant que c'est une syntaxe valide ...
Est ce que cette négation tient compte d'une valeur de 0 ou 1 ?
Ou ça ne serait pas plutôt NULL (ou éventuellement rien/inéxistant) ? Dans ce dernier ça, 0 ou 1 n'étant pas NULL, c'est comme si c'était VRAI (ce qui justifierait peut être le dysfonctionnement).

Mais je fabule peut être, c'est une idée.


Petite parenthèse en passant, et à titre perso.
Je privilégierais plutôt des jointures naturelles comme JOIN, INNER JOIN
que de simple égalités comme : cibles.id = refCible actuellement.

[gene69]

Pour ce qui est de l'abscence de log, à mon avis ce serait plus simple si tu avais une possibilité de loguer tout ce qui va à travers mysql_query() ou sont équivalent nativement dans la classe de surcouche et pas dans un bout de code qui ne donne pas l'impression d'y être.

En plus avec un peu d'astuce tu peux tres bien remonter dans la pile debug_backtrace() pour retrouver le fichier et la fonction qui lance l'appel à select(), execute().. ma surcouche perso est assez naïve pour que ce soit simple puisque je n'ai qu'une méthode query() à surveiller. C'est pour ça que je pose la question du framework.

[dubitoph]

Bonsoir et merci beaucoup de l'attention que tu portes à mon problème. Je patauge grave depuis plusieurs jours...

Concernant l'editeur, j'utilise PhpEdit.

Ensuite, voici la portion de code dans laquelle je flague le suivi comme étant en cours de traitement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
$retour = $objCampagne->chargerCible($tabVendPrior); //Là, je charge une cible dont le suivi n'a pas son champ "occupe" à 1
 
if(is_array($retour))
 {
  $objCible = new CCible($retour);
 
  if(!isset($_SESSION['campagne'])) //Pour le premier appel effectué à partir de listeCampagnes.inc
   $_SESSION['campagne'] = serialize($objCampagne);
 
  $_SESSION['cible'] = serialize($objCible);
 
  $objSuivi = $objCampagne->chargerSuivi($retour['id']);
  $objSuivi->setOccupe(1); // Ici, je flague mon suivi comme étant occupé

Voici le code de ma méthode setOccupe() :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
public function setOccupe($occupe)
   {
    $this->occupe = $occupe;
    $tab['id'] = $this->id;
    $tab['occupe'] = $occupe;
    $transaction = CtransactionsBdd::GetInstance("MYSQL", "speedcall");
    $resuReq = $transaction->update("MYSQL_suiviOccupe", $tab);
   }

Concernant le !cloture, c'est simplement pour savoir si le traitement du suivi est terminé ou si il doit y avoir encore des traitements ultérieurs. Le problème ne vient pas du champ cloture, mais du champ occupe.

J'ai essayé la synthaxe

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

and occupe <> 1

, mais cela n'a rien changé.

[gene69]

Concernant l'editeur, j'utilise PhpEdit.

framework != editeur de texte.

soit t'es distrait, soit t'es stagiaire.

Ca se confirme: Teste ta valeur de retours de la mise à jour, lance une exception si c'est anormal et enleve les !cloture comme te le conseille avec justesse RunCodePhp, d'abord parce que si par hasard ça marche c'est pas l'usage d'utiliser cette syntaxe.

[RunCodePhp]

Je vois aussi que tu utilise des transactions (CtransactionsBdd), qu'un update est effectué, mais je ne vois pas de commit ?
C'est normal ? (c'est effectué dans la fonction ?)
Est ce réellement une transaction d'ailleurs ?

[dubitoph]

Je n'utilise pas de framework, j'utilise en connaissance de cause un éditeur.

Quand à mon champ clôturé, il ne pose pas de problème, c'est bien le champ occupe qui apparemment l'est (le champs cloture ne fait rien que m'indiquer qu'il n'y aura plus de traitement à effectuer pour ce suivi).

Par contre, j'ai testé directement la mise à jour de mon champ occupé de la façon suivante : j'ai exécuté mon code (donc effectué un appel), puis, avant de terminer le traitement de celui-ci, j'ai vérifié, via une requête dans PhpMyAdmin que mon champ occupe avait bien pris la valeur 1, ce qui était le cas.

Ce qui m'étonne, c'est que si je lance à ce moment la requête de sélection d'une cible (et suivi) dans PhpMyAdmin, il ne me sélectionne pas (de manière correcte), le suivi occupé. Par contre, si je le fais via une autre session dans mon application, là il me ramène (de façon erronée) le suivi occupé

[dubitoph]

Je vois aussi que tu utilise des transactions (CtransactionsBdd), qu'un update est effectué, mais je ne vois pas de commit ?
C'est normal ? (c'est effectué dans la fonction ?)

Je pense que la nomination de CtransactionsBdd n'est pas très heureuse, car en MySql, il n'y a pas de transaction, tout s'effectuant en direct (j'aurais dû nommé cela en CconnexionBdd). Il n'y a donc pas (selon moi) de commit à effectuer.

[RunCodePhp]

Je pense que la nomination de CtransactionsBdd n'est pas très heureuse, car en MySql, il n'y a pas de transaction, tout s'effectuant en direct. Il n'y a donc pas (selon moi) de commit à effectuer.

Je m'en doutais un peu ... c'était au cas où
Mais pour le nom, c'est vrai que ...

Par contre, si je le fais via une autre session dans mon application, là il me ramène (de façon erronée) le suivi occupé

As tu affiché l'intégralité des données récupérer pour tenter de voir ce qui serait incohérant, car il doit avoir quelque chose d'incohérent pour quelle passe.
(au niveau de l'appli, vu que coté PhpMyAdmin tu l'as déjà fait).

Est ce juste le "occupé" qui est à 0 ? (au lieu de 1)

Y a t-il une date de mise à jour ?
(je ne sais pas si ça peu aider à comprendre le problème)

[gene69]

Je pense que la nomination de CtransactionsBdd n'est pas très heureuse, car en MySql, il n'y a pas de transaction, tout s'effectuant en direct (j'aurais dû nommé cela en CconnexionBdd). Il n'y a donc pas (selon moi) de commit à effectuer.

et bien je ne suis pas d'accord. On peut faire des transactions avec mysql.

apparemment ma piste ne plais pas, je me dit que ça aurai été sympa d'avoir un ptit retour de la base comme quoi le drapeau à bel et bien été positionné.

Pis mon idée de loguer tout ce qui va dans le mysql_query() ça permet de verifier si ya pas de contre-ordre appelé par un objet de façon mal maitrisée (genre un destructeur ... ) Pisque c'est une classe maison ça devrait pas être très compliquer à modifier.

Tentons autre chose, pour ne pas passer pour un rigolo:

Lors de la première exécution, je retrouve bien la requête dans le fichier texte. Par contre je n'y retrouve aucune trace d'une autre requête, alors que les deux mêmes fiches client sont affichées à l'écran.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$inF = fopen($Fnm,"w");

or je consulte la doc:

'w' Ouvre en écriture seule ; place le pointeur de fichier au début du fichier et réduit la taille du fichier à 0. Si le fichier n'existe pas, on tente de le créer.

[dubitoph]

Je viens de modifier toutes mes requêtes en remplaçant ! occupe par occupe = 0 et ! cloture en cloture < 1.

Toujours le même problème.

[gene69]

ouaip mais maintenant tu as un log qui fonctionne.
Il serait intégré à la classe d'acces au donnée ça serait encore plus sur, et en plus tu pourrais voir passer les select, les update et rejouer tout ça.

à tout hasard l'autocommit est-il bien activé?

[dubitoph]

Merci pour l'info concernant l'écriture dans un fichier, je m'étais de fait planté.

Donc j'ai recommencé les tests avec mes requêtes modifiées et la modification de w en a+.

Le problème subsiste toujours, par contre, dans le fichier texte, je retrouve bien mes deux select :

"select cibles.* from cibles, suivis where refCampagne = 1 and cibles.id = refCible and cloture < 1 and rappelPrior = 1 and (dateRappel > date_sub(curdate(), interval 1 day) and dateRappel < date_sub(now(), interval 15 minute)) and occupe = 0 order by dateRappel desc limit 1

select cibles.* from cibles, suivis where refCampagne = 1 and cibles.id = refCible and cloture < 1 and rappelPrior = 1 and (dateRappel > date_sub(curdate(), interval 1 day) and dateRappel < date_sub(now(), interval 15 minute)) and occupe = 0 order by dateRappel desc limit 1
"

[gene69]

le coup du w ça m'arrive souvent.

Ce qui est terrible c'est que je ne connais tes méthodes de débug du coup j'essaie d'appliquer les miennes qui conviennent à mes outils.

bon j'essaie de retracer le scénario en attendant est ce que tu peux m'expliquer chargerCible en pseudo-code?
je bloque un peu sur ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
    $resuReq = $transaction->select("MYSQL_chargerCibleLapsTempsEnCoursPrior", $tab); // On charge une cible dont la date de rappel indiquée par l'utilisateur se situe dans le laps de temps +- 15 minutes par rapport à l'heure actuelle
 
    if ($transaction->getErreur() == "Aucun résultat")
     {
      $resuReq2 = $transaction->select("MYSQL_chargerCibleRappelDateJourPrior", $tab); // On charge une cible dont la date de rappel indiquée par l'utilisateur est celle du jour

je ne dis pas que c'est faux. je dis que je ne comprends pas.

[gene69]

Quand je lis ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
$objUtilisateur = unserialize($_COOKIE['utilisateur']);
$objUtilisateur->getId();

je me dit que tu ne crains pas l'usurpation d'identité.

bon je continue à chercher. Ceci dit je veux bien voir un peut plus de code pour savoir comment tu traites les resultats de tes 2 requetes SQL.

[gene69]

Bon ya une autre chose que j'aimerai comprendre. Pourquoi tu ne laisses pas la persistance des objets à la bases de données et ne laisser les sessions php que pour des informations volatiles, genre login/id...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  $_SESSION['cible'] = serialize($objCible);
  $objSuivi = $objCampagne->chargerSuivi($retour['id']);
  $objSuivi->setOccupe(1);

Si tu peux me démontrer qu'il n'y a pas d'erreur dans ce bout de code, j'arrête de t'aider parce que j'ai épuisé tous mes indices. Bon si tu n'y arrives pas, j'arrête quand même, c'est ça qui est bien.

[dubitoph]

ouaip mais maintenant tu as un log qui fonctionne.
Il serait intégré à la classe d'acces au donnée ça serait encore plus sur, et en plus tu pourrais voir passer les select, les update et rejouer tout ça.

à tout hasard l'autocommit est-il bien activé?

Travaillant ave Wamp, je ne trouve pas de notion d'AUTOCOMMIT". Par contre, par le passé, je n'ai jamais rencontré ce genre de problème, utilisant même le LAST_INSERT_ID().

Concernant l'explication de ma méthode chargerCible(), la voici :

- je regarde si j'ai un suivi qui possède une date de rappel qui se situe dans le laps de temps = ou - 1/4h par rapport à l'heure courante et qu'il est flagué comme étant un rappel prioritaire
- si oui, j'efffectue l'appel correspondant, sinon, je regarde si j'ai un suivi qui possède une date de rappel qui est égale à la date du jour et qu'il est flagué comme étant un rappel prioritaire
- si oui, si oui, j'efffectue l'appel correspondant, sinon, si je dois traiter des vendeurs en priorité, je regarde si j'ai un suivi dont la cible est gérer par le vendeur pour qui il faut prendre des rendez-vous en priorité.
- etc...

[dubitoph]

Quand je lis ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
$objUtilisateur = unserialize($_COOKIE['utilisateur']);
$objUtilisateur->getId();

je me dit que tu ne crains pas l'usurpation d'identité.

bon je continue à chercher. Ceci dit je veux bien voir un peut plus de code pour savoir comment tu traites les resultats de tes 2 requetes SQL.

Comme c'est une application en intranet, ça ne me tracasse pas trop...