+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : [Résolu] Structure des tables pour un Ogame-like (/showthread.php?tid=4581)
RE: Structure des tables pour un ogame-like - Sephi-Chan - 16-02-2010
Je pense que ce serait une erreur de ne pas mettre d'index sur des colonnes souvent sollicitées.
Sephi-Chan
RE: Structure des tables pour un ogame-like - php_addict - 16-02-2010
salut
(16-02-2010, 04:44 PM)Sephi-Chan a écrit : Je pense que ce serait une erreur de ne pas mettre d'index sur des colonnes souvent sollicitées.
effectivement je plussoie , je ne me servais que médiocrement des index, et je dois dire que c'est indispensable
RE: Structure des tables pour un ogame-like - QuentinC - 17-02-2010
Je reviens de nouveau vous poser une question, la dernière, enfin j'espère (depuis le temps que je dis que ça va être la dernière...). Cette fois-ci c'est sûrement la plus compliquée de toutes.
Comment faire pour éviter qu'un évènement impliquant deux joueurs ne soit exécuté deux fois ?
J'imagine le scénario-catastrophe suivant :
0. Un combat est programmé entre A et B
1. A se connecte, la liste des évènements est récupérée et le calcul du combat démarre
2. Pendant ce temps, B se connecte, récupère la liste des évènements et voit aussi qu'il y a un combat à traiter.
3. Le calcul du combat est terminé chez A, l'évènement correctement traité est effacé. Tout va bien.
4. Le calcul du combat est terminé chez B. ON tente de supprimer l'évènement une deuxième fois mais rien ne se passe et pourtant tout va bien. Alerte au bug ! le combat a eu lieu deux fois !
JE vois bien une solution bourrin, mais il doit y avoir plus simple pour prévenir de ce genre de bug.
Inutile de rappeler qu'une requête dans une boucle est un véritable auto-suicide propre à soi-même de la mort qui tue conduisant à un terrible cataclysme inéluctable et apocaliptique pour les performances.
Code :
while ($db->value('select @flag')>0) usleep(10); // carton rouge
$db->exec('set @flag = 1');
// traitements à effectuer
$db->exec('set @flag = 0');De plus, je ne vois pas en quoi les transactions règleraient le problème. Parce qu'on pourrait avoir ce scénario-là :
1. A se connecte et commence une transaction
B. A récupère la liste des évènements et voit le combat
3. A traite le combat
4. A sauvegarde
5. B se connecte et commence une transaction. Pas de problème vu que les deux connexions à MySQL sont indépendantes
6. B récupère la liste des évènements. A n'a pas encore commit donc B voit toujours le combat dans la liste des évènements récupérée
7. A commit
8. B traite le combat
9. B sauvegarde
10. B commit. Résultat : le combat a été effectué deux fois quand même.
Ou alors est-ce que je suis paranoïaque et les scénarios que j'expose ne peuvent techniquement jamais arriver ?
RE: Structure des tables pour un ogame-like - Anthor - 17-02-2010
Citation :#
All InnoDB locks held by a transaction are released when the transaction is committed or aborted. Thus, it does not make much sense to invoke LOCK TABLES on InnoDB tables in autocommit = 1 mode, because the acquired InnoDB table locks would be released immediately.
#
Sometimes it would be useful to lock further tables in the course of a transaction. Unfortunately, LOCK TABLES in MySQL performs an implicit COMMIT and UNLOCK TABLES. An InnoDB variant of LOCK TABLES has been planned that can be executed in the middle of a transaction.
En gros c'est implicite, et on y a déjà pensé pour toi ^^
RE: Structure des tables pour un ogame-like - QuentinC - 17-02-2010
Donc autrement dit le scénario n°2 est impossible, les deux jeux de requêtes s'exécutent successivement. Ais-je bien compris ?
RE: Structure des tables pour un ogame-like - Anthor - 18-02-2010
A peu de choses près, même si c'est un peu plus compliqué que ça.
Exemple : Je démarre une transaction, sur une table X, mais plus tard, j'ai besoin de locker Y. MySQL, va commiut, unlock, et lock X et Y.
M'enfin, déjà, le scénario à la base, et très hypothétique, car il faut que 2 personnes ayant, un event commun, affiche au même time, une page. Ça réduit les possibilités :p
RE: Structure des tables pour un ogame-like - QuentinC - 21-02-2010
Merci pour toutes vos réponses.
ON peut maintenant dire que le sujet est résolu.
RE: Structure des tables pour un ogame-like - php_addict - 21-02-2010
si quelqu'un a le courage de faire un tuto sur les executions multiples et les tranaction...j'ai l'impresion que ce questionnement est recurrent
bonne journée
RE: Structure des tables pour un ogame-like - Sephi-Chan - 21-02-2010
C'est vrai qu'on a jamais autant parlé de PDO et des transactions que ces dernières semaines.
Le wiki est là, donc si vous voulez écrire, vous savez où aller !
Sephi-Chan