resolution liste d'actions : reinjecter de nouvelles actions?

[php_addict]

[niahoo]

has gone away il me semble que c'est quand le serveur tient pas la charge.

edit : premier lien sur cette page de doc : Mysql doc (edit, non deuxieme, le premier est en anglais

[Asphodèles]

Je suis tombé sur le sujet et je m'y suis intéressé sans avoir le temps d'approfondir, alors sens-toi libre d'ignorer complètement mon avis. En plus je n'ai pas pu regarder le bout de code que tu viens d'envoyer.

Est-ce que ça ne vaudrait pas le coup au début de créer une nouvelle table "in memory" dans laquelle tu ferais toutes tes opérations ? tu la crées selon le select initial de la table en dur, puis tu fais toutes tes opérations de résolutions/injections dessus et à la fin, (si tu as besoin d'en garder une trace dans la table d'origine) tu recopies dans la table en dur.

[php_addict]

Est-ce que ça ne vaudrait pas le coup au début de créer une nouvelle table "in memory" dans laquelle tu ferais toutes tes opérations ?

il me faudrait un dédié pour ca, et ca va être chaud...je suis en train de graver debian sarge...

[Myrina]

Je pencherai plutôt pour un deadlock vu le contexte et les symptômes. Pour expertiser plus loin, il faudrait connaître le contenu de la fonction resolution_actions_non_resolues notamment les ordres INSERT/UPDATE/DELETE qui la contiennent.

Sinon, pour générer un deadlock et donc "bloquer" la base de données, c'est très simple, il suffit de:
* sur une transaction A, faire une MAJ d'une table X
* sur une transaction B, faire une MAJ d'une table Y
* sur la transaction A, faire une MAJ de la table X
* sur la transaction B, faire une MAJ de la table Y

La transaction A attend que la table X soit libéré (commit ou rollback de B) pour continuer son travail et faire son commit/rollback.
Et la transaction B attend que la table Y soit libéré par A pour continuer son travail et faire son commit/rollback.

Ceci est valable si la gestion des verrous est positionné sur la table; normalement elle devrait pouvoir être mise au niveau des occurrences. Je ne connais pas assez MySQL pour connaitre son fonctionnement précis la dessus.

L'autre point important, c'est la taille des transactions et la durée de celles-ci: il faut qu'elles soient le plus concis et rapide possible.

[Asphodèles]

php_addict, t'es sûr que tu n'as pas memory comme moteur de stockage ? Je n'y connais rien en technos web, donc j'imaginais même pas qu'il puisse y avoir une limitation à ce niveau.

Après vérification chez l'hébergeur gratuit que j'utilise pour tester http://000webhost.com, MEMORY est bien présent (j'ai pas innoDB par contre).

[php_addict]

php_addict, t'es sûr que tu n'as pas memory comme moteur de stockage ?

ah si, pardon, je viens de vérifier, mais en quoi ca m'aiderais?

Je pencherai plutôt pour un deadlock vu le contexte et les symptômes.

oh la vache...gros coup au moral sur ce coup là...

je ne savais même pas ce que c'était un deadlock...2 ans de boulot pour en arriver là, les boules...c'est quasiment certain que c'est ca...

mes résolutions d'actions sont englobées dans une transaction et font des opérations sur différentes tables...

alors là je suis dans une mouise totale: car j'ai besoin du systeme de transaction pour éviter qu'une action soit résolue plusieurs fois, et en même temps j'ai besoin de faire des manip sur différentes tables...j'suis mal barré...

[niahoo]

Ton problème c'est de compter sur le chargement de pages par les visiteurs pour résoudre tes actions. Trouves un autre moyen: page d'admin qui se recharge en boucle, fork du processus php, ...

[php_addict]

bon, désolé pour mon précédent post alarmiste je pense savoir d'où venait le soucis, j'avais un FOR UPDATE dans une requête...j'ai viré le FOR UPDATE

par contre dans ma boucle primaire de résolution d'action (voir code plus haut svp) il semble que le FOR UPDATE soit nécessaire alors que la requête est dans une transaction...

je pensais qu'une transaction bloquait automatiquement en écriture toutes les tables concernées, non ?

car si je ne met pas le FOR UPDATE, mes actions sont résolues plusieurs fois (quand 2 navigateurs de 2 joueurs tentent de résoudre la meme action au meme mpment)

merci pour tout vos conseils, bonne journée ensolleillée

[Myrina]

Quel est le moteur MySQL utilisé?

Ceci est très important car impactant pour la gestion des verrous => http://dev.mysql.com/doc/refman/5.0/en/i...cking.html