[Résolu] Structure des tables pour un Ogame-like

[Sephi-Chan]

Je pense que ce serait une erreur de ne pas mettre d'index sur des colonnes souvent sollicitées.


Sephi-Chan

[php_addict]

salut

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

[QuentinC]

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 ?

[Anthor]

#

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 ^^

[QuentinC]

Donc autrement dit le scénario n°2 est impossible, les deux jeux de requêtes s'exécutent successivement. Ais-je bien compris ?

[Anthor]

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

[QuentinC]

Merci pour toutes vos réponses.
ON peut maintenant dire que le sujet est résolu.

[php_addict]

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

[Sephi-Chan]

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