[MySQL] Verrous et résolution d'action

[niahoo]

Oui mais rappelle toi tout ça c'est justement pour éviter les race conditions : en gros le mec spam un bouton d'achat et donc le code qui vérifie qu'il a bien 500 po est exécuté 2 fois quasi simultanément PUIS le code qui lui attribue l'item acheté etexécute -500 sur ses thunes est exécuté simultanément. Donc avec 500 po il s'achete une valeur de 1000 po.

D'où le besoin de le faire dans une transaction mysql, mais comme visiblement son système permettait quand même (étrangement) des updates concurrents, il a envisagé les lock => et la on lui conseille de le mettre dans une queue pour s'assurer de l'atomocité des transactions.

C'est un peu overkill mais si j'ai bien résumé (j'ai pas relu les 2 topics) ça semble plutot simple a gérer et ça marcherait.

[Sephi-Chan]

J'avais oublié que notre cher addict aimait traiter des problèmes imaginaires !
Dans ce cas, Resque évitera ce cas si les deux tâches se trouvent dans la même queue et qu'un seul worker traite ce type de queue.

[php_addict]

Du coup vous me faites douter...car voici des exemples d'actions à résoudre (comme pour un wargame):

à 15h15 --> résolution de l'attaque du joueur 1 sur le joueur 2 (et pillage de crédits) - l'action à été lancée à 10h00
à 15h20 --> résolution de la construction du bâtiment QG - l'action à été lancée à 02h00
à 15h25 --> résolution de l'arrivée de l'assistance du joueur 3 vers le joueur 4 - l'action à été lancée à 15h22

je ne suis pas certain que les queue sont adaptées car les actions sont lancées à un certain timestamp et seront résolues plus tard, elles ne peuvent donc pas s'empiler dans la queue de façon chronologique...

il est donc nécessaire de les stocker dans une bdd pour pouvoir prendre les actions à résoudre en partant des plus anciennes (timestamp de résolution et non d'activation)

peut être n'ai je pas été très clair lors de mes précédents post, mais je ne pense donc que je ne peut pas utiliser des queues. non ?

La résolution des actions est déclenchée à chaque rafraichissement de la page web par le/les joueurs, d'où les problèmes d'accès concurrents.

Le job queue est donc inapproprié non ? ou bien je n'ai rien compris du tout...

[Sephi-Chan]

Il y a 2 choses : le queueing et le queueing + scheduling.

Avec Resque et Resque Scheduler, tu peux faire plusieurs choses :

# Le job est empilé sur le champ (et sera probablement dépilé dans la foulée, à moins que tes workers ne soient chargés).

Resque.enqueue(ResolveAttackJob, attacker.id, target.id)



# Sera empilé sur la queue à la date prévue (ici, maintenant + 2 heures).

Resque.enqueue_at(2.hours.from_now, ResolveAttackJob, attacker.id, target.id)



# Sucre syntaxique, le résultat sera le même que le précédent appel.

Resque.enqueue_in(2.hours, ResolveAttackJob, attacker.id, target.id)

À côté de ça, la classe ResolveAttackJob aura cette tronche :

class ResolveAttackJob

  @queue = :attacks

  

  def self.perform(attacker_id, target_id)

    # ...

  end

end

Normalement tu as de quoi couvrir tes besoins.

[php_addict]

Bonjour

au sujet des lock, dans un premier temps voici ce que je fais et cela semble fonctionner:

//___________________________________________________________________________________

// definit le niveau d'isolation innodb ( SERIALIZABLE = maximum) pour cette session |

//___________________________________________________________________________________|



$query   = " SET SESSION TRANSACTION ISOLATION LEVEL SERIALIZABLE ";

$result  = $connexion_mmorpg->prepare("$query");  

$result->execute();  

//



$connexion_mmorpg->beginTransaction(); 

//

//

//

//

$connexion_mmorpg->commit();

dans un premier temps j'avais mis SERIALIZABLE par defaut dans le fichier de conf de mysql, mais tout accès à la bdd était très lent (forcement cela lockait tout, tout le temps)

je vais me pencher sur les queue mais je vous explique même pas la galère...j'ai lu tout un tas de truc sur redis/resque mais je rame complétement, et comme c'est vraiment un truc de geek les articles/tutos sont assez complexes, même ceux en français...)

pas si évident que ca les queue...

[Sephi-Chan]

Tu aimes bien te compliquer la vie quand même… Te préoccuper des choses qui ne servent à rien et dont tu ne pourras même pas constater l'effet…

Pour Redis, c'est sûr que c'est pas évident, surtout si tu as l'habitude des packages genre WAMP. Tu tentes de le mettre en place sur un Windows ou un Linux ?

L'utilisation des queues est très simples, c'est l'architecture qui est un peu difficile parfois. Mais si on y réfléchit, ce n'est pas plus compliqué que mettre un Apache en place avec ses virtual hosts.

[php_addict]

j'ai deja un kimesufi/ubuntu que j'utilise pour le développement de mon projet et pour heberger quelques anciens sites MFA (made for adsense)

installer redis ne va pas me poser de problème mais c'est l'utilisation de resque (ou autre) qui va me poser problème, car les exemples de code genre "make your tweeter like with resque" sont déjà bien trop balaises pour moi, et c'est presque un langage à part entière avec lequel j'ai un peu de mal...impossible de trouver un exemple de code php/resque ultra simpliste...ca va vraiment être galère...

[Sephi-Chan]

Je ne comprends pas trop. Le code donné sur https://github.com/chrisboulton/php-resque me paraît très compréhensible.
Qu'est-ce que tu n'arrives pas à faire concrètement ?

[php_addict]

pour le moment c'est vraiment très abstrait, faudrait que je commence par faire un truc simple mais concret

[php_addict]

salut

je reviens sur ce sujet (apolitique )car je ne suis pas certain de comprendre : si je fais quelque chose comme ca:

Code :

Resque.enqueue_in(2.hours, ResolveAttackJob, attacker.id, target.id)
Resque.enqueue_in(2.hours, ResolveAttackJob, attacker.id, target.id)

et que les 2 "ResolveAttackJob" se lancent au même moment quasiment, apache va me lancer 2 process? donc il y aura concurrence potentielle d’accès à la base de donnée non ?

je ne suis pas certain que le schedulding règle les problèmes de concurrence d’accès à la base de donnée en cas de scheduldings simultanés...

non?