[MySQL] Verrous et résolution d'action

[php_addict]

Bonjour, merci pour vos réponses

Il peut y avoir de lourdes requêtes SQL qui vont certainement faire s'empiler les transaction, genre un mysqldump, ou un restart du serveur dédié, je suis sur qu'il y a mille autres raisons pour que des requêtes concurrentielles se produisent sans parler de milliers de joueur...

Les LOCK TABLE couplés aux transactions ne sont t ils pas un bon moyen de faire un job queue en php? Mes actions sont stockée en base de donnée et traitées les une après les autres, le seule problème étant les requêtes simultanées ou concurrentielle

je ne suis pas certain de comprendre pourquoi LOCK TABLES seraient une si mauvaise solution que ça...

petits hors sujet:

- je me demande si un job queue est php n'est pas possible avec un système de long polling, un script qui tourne en rond comme pour un chat+socket

- je me demande comment font "les grands" genre travians games, tribal war, ikariam et compagnie...

[niahoo]

Les grands ont un serveur dédié et des daemons dédiés pour la gestion des queues. En amateur ça commence par un cron.

Tu peux te faire un cron maison avec du long-polling mais ça va t'obliger a avoir constamment un navigateur ouvert sur ton jeu.

Le jour ou tu as une coupure internet, ton jeu se stoppe ?

Sur du mutualisé, webcron peut suffire. il faut voir..

[Sephi-Chan]

Je t'invite à lire ces slides très intéressants : Concurrency Control: How It Really Works.

Une job queue ne se fait pas avec du long polling ou quoi que ce soit lié au client. Redis (et je crois que c'est pareil avec RabbitMQ et compagnie) implémente un mécanisme de publish/subscribe qui va permettre de maintenir une queue (ou plusieurs) en envoyant des éléments dedans, avec un peu de données.

Dans Conquest on Rails, j'insère dans la queue un élément avec 2 informations : le nom d'une classe et l'id de la partie à lancer. Redis se fout de ces données, il les stocke juste.


Ensuite, d'autres programmes vont pouvoir écouter cette file et en dépiler les éléments pour en faire quelque chose. On appelle généralement ces processus des workers.

Pour reprendre l'exemple, ce travail est effectué par Resque (écrit en Ruby, mais un portage en PHP a été fait), qui va savoir quoi faire des informations qu'il dépile. Il va regarder le nom de la classe qu'on a renseigné et appeler sa méthode de classe (= statique) perform en lui passant en argument les autres informations qu'on a donné (en l'occurrence, l'id de la partie).

[php_addict]

merci encore une fois de plus à vous tous

malheureusement pour le moment je suis dans l'incapacité neuronal/intellectuel et technique d'utiliser Resque (ou autre) donc:

est il tout de même envisageable de LOCK les tables? (j'ai l'impression d'être pénible là...)

- J'entre dans la transaction
- je LOCK les tables susceptibles d'être concurrentielle
- je résous mes actions
- je UNLOCK tout
- et je ferme la transaction

ca devrait fonctionner non?

je comprends bien l’intérêt de Resque mais je ne vois pas pourquoi LOCKer les tables est si inacceptable pour vous pour gérer les "race conditions", ca sert pas à ça les LOCK ? Techniquement c'est possible non? même si une système de queue est meilleur j'en suis conscient...

[mode blues]
après 1300 post sur ce forum j'ai toujours l'impression d'avoir encore 1000 choses à apprendre...c'est pénible...
[/mode blues]

[niahoo]

Ce qui est pénible c'est qu'on te dis tous que c'est une solution pas terrible, mais que tu la fais quand même. Alors j'ai envie de te dire : testes, et tu verras bien si ça fonctionne comme tu veux.

Mais l'incapacité technique/neuronale j'y crois pas vraiment, c'est à mon avis plus facile que de monter tout un système de locks.

[php_addict]

ok ok désolé...

j'aimerais juste comprendre pourquoi c'est une solution si merdique...

[Sephi-Chan]

C'est ultra violent un lock global de table : aucune autre écriture possible jusqu'au relâchement.
Après, Niahoo a raison : le mieux c'est de tester si ça convient. Mais à mon avis tu anticipes beaucoup trop les problèmes.

C'est un peu comme la Premature Optimization. ^^

[srm]

Tu peux faire si tu es en InnoDB ça devrait bien passer, ça lockera que les lignes ou tu travailles

[Sephi-Chan]

C'est ce dont parle les slides que j'ai évoqué mais je n'ai eu aucun retour sur le sujet…

Je t'invite à lire ces slides très intéressants : Concurrency Control: How It Really Works.

[php_addict]

Salut

j'ai fais des PNJ qui jouent automatiquement certaines actions, pour tester les requetes concurentielles, je vous tiens au courant