06-03-2012, 09:10 PM
(06-03-2012, 05:03 PM)niahoo a écrit : atra, as-tu testé ton système ? parce que quand tu charges 10 prochaines actions, tu bloques le jeu pour tout le monde avec ta transaction, et ce le temps d'en résoudre 10. AS-tu testé de lancer deux requêtes simultanées pour voir si ça fonctionnait ?
L'idée c'est pas vraiment de résoudre les 10 suivantes, mais plutôt de résoudre un joueur.
(Encore est toujours a cause des contraintes de mon gameplay)
et c'est la l'interet du lock manuel!
User 1 n'a pas d'action a résoudre pour lui, il résous celles de user2. Il locke donc les actions (manuellement, puis pose un verrou mysql sur les données quand il les lit pour résoudre l'action en question).
User 2, qui charge sa page, veut se mettre a jour, sauf que comme les actions sont lockées, le code d'update passe tout droit.
Le code d'affichage, lui, récupère les données dont il a besoin:
-Soit les données sont disponibles il les charges et les affiche...
-Soit les données sont lockées (verrou de la base sur le champ), le système attend que user1 ai fini de résoudre cette action et ai déverrouillé...
Bref dans tous les cas, l'action est effectuée avant l'affichage, peut importe si c'est user2 lui même ou user1 qui le met a jour.
Cela a pour effet de gommer les temps sans MAJ pour les non connectés (qui ne se mettent pas a jour sinon...)
Bon c'est pas aussi clean et optimal qu'un systeme de queue avec sheduling, mais dés que j'ai un dédié, je me code un daemon pour gérer ces résolutions d'actions a la noix!
Pour le cas d'Argorate, vu que les actions sont résolues après le clic directement, il y a que deux solutions:
On calcule -> on envoie (ça marche si c'est vraiment pas long)
On met en queue -> on envoie -> on calcule -> on complète le premier envoi
Pour le reste, les verrous/transactions mysql devraient régler le problème.