[MySQL] Verrous et résolution d'action

[php_addict]

Bonsoir

encore moi, avec tout un tas de questions de noob...désolé...Car comme un crétin je pensais que les transactions Mysql mettaient automatiquement des verrous un peu partout..quel con...'fin bref

voici tout d'abord du pseudo code, il s'agit de résoudre des actions tels que "payer" "contruire un batiment" "recruter" etc...la question sur les verrous sera plus bas

<?php



function resolution_action()

{

	try

	{

		$connexion_mmorpg->beginTransaction(); 

		

		// si action == "payer"      ---> modification de la table joueurs (joueurs.argent)

		// si action == "construire" ---> modification de la table batiments

		// si action == "recruter"   ---> modification de la table troupes

		//

		// etc...

		//



		$connexion_mmorpg->commit();

	}

	catch(PDOException $e)

	{

		$connexion_mmorpg->rollBack();

	}

}



?>

Il va falloir que je pose des verrous sur mes tables pour éviter les problèmes des clients simultanés, et là je patauge un peu...

quels type de verrous dois-je utiliser? SELECT FOR UPDATE ? LOCK TABLE?

prenons une action qui va modifier 2 tables: table A et table B:

je fais quoi? je LOCK les 2 tables consécutivement, je fais mes petits UPDATE et je UNLOCK tout?

en réalité ce qui me fais bien flipper ce sont les deadlock...

merci de m'avoir lu et merci à ceux qui prendront le temps de me répondre

bonne soirée

[srm]

Lock rien tu t'en fou

[Sephi-Chan]

Pourquoi est-ce que tu voudrais lock tes tables ?

[niahoo]

à cause des accès concurrents et des race conditions. si au temps 0 tu lances un pillage de village, au temps 1 le mec transfère ses ressources vers un autre village, au temps 2 le pillage est effectué et revient bredouille alors que ton espion t'as indiqué 5 secondes avant que le grenier était plein de jambonneau c'est pas cool.

Maintenant, est-ce que le lock est une bonne solution ? je dirais que non, bienvenue dans le temps réel : soit tu crées une queue d'évenements (et PHP (encore lui, saligaud) ne le permet pas, soit "Lock rien tu t'en fous" semble une solution acceptable.

[Ter Rowan]

soit tu crées une queue d'évenements (et PHP (encore lui, saligaud) ne le permet pas,

et si tu fais ta queue en bdd ? ça ne marcherait pas ?

[niahoo]

ouais mais tu serais obligé d'exécuter la queue via les requêtes des utilisateurs, et tu retombes dans le problème des race conditions.

[Sephi-Chan]

Il y a mieux pour les queues : le couple Redis + Resque, par exemple. Comme Redis implémente un système de publish/subscribe, tu peux facilement avoir un daemon (genre un worker Resque) qui traite la queue.

Bien sûr, ça demande du dédié, comme toutes les solutions sérieuses.

Mais à mon avis, ce problème n'existera pas avant fort, fort longtemps. Je n'hésiterais pas à l'ignorer et à ne le traiter que s'il devient menaçant. :p

[Ter Rowan]

Je n'hésiterais pas à l'ignorer et à ne le traiter que s'il devient menaçant. :p

Je pensais aussi la même chose,mais est ce que, si cela arrive, il est simple de basculer? Est ce que cela ne nécessite pas une refonte importante du code et de l'architecture ?

[srm]

Mon avis est que c'est inutile puisqu'à moi d'avoir un gros volume de joueur, un très gros volume de joueur, le cas ou quelqu'un va déplacer ses ressources et l'autre piller PILE en même temps n'arrivera sans doute jamais.

Tu auras toujours une nano seconde de différence ou l'un sera arrivé avant l'autre. Sauf si tes requêtes mettent trois plombes

Quoi qu'il en soit, utiliser une queue est plus adapté si tu tiens vraiment à te prémunir de ça.

[Sephi-Chan]

Si, ça peut être un changement conséquent. Mais pour être honnête, c'est un problème de grande personne. Il faut commencer à avoir une application qui tourne vraiment très bien (des milliers de joueurs en même temps) pour y faire face. Pour perturber un ordinateur capable de faire des opérations si rapidement, il faut vraiment beaucoup d'accès en un instant.

Il faut peser le pour et le contre : mettre en place du queueing implique déjà l'utilisation d'un dédié et les coûts qui vont avec.
Sans, on ne risque pas grand chose mais on peut garder notre application plus simple.

Bien sûr que si le développeur est familier avec ça, utiliser le queueing/scheduling est toujours intéressant. Cf. mon article L'asynchrone, pourquoi et comment ?. Mais il faut se donner les moyens de ce qu'on veut.

Je prends mon jeu Conquest on Rails, par exemple. Voilà les processus dont il a besoin pour fonctionner : Redis, Resque et Resque Scheduler sont dédiés au queueing. Et malgré que je n'ai qu'un type de queue pour le moment (celle pour démarrer les parties qui ont atteint le nombre de joueurs requis), c'est déjà très intéressant dans la mesure où l'opération de démarrage d'une partie fait une centaine d'update dans la base de données.