Discussion :

[gazelle]

Bonjour,

Je tourne en rond depuis 4 jours sur une problématique que je n'arrive pas à résoudre.

Je publie un évènement sur mon site Web pour lequel des utilisateurs peuvent s'inscrire.

- Dans mon cas, j'ai besoin de 2 utilisateurs seulement.
- Le site gère seul le fait que les 2 premiers inscrits auront le statut "accepté" d'office (premier arrivé : premier servi).
- 2 autres utilisateurs peuvent s'inscrire mais auront le statut "sur file d'attente".


Le problème :
- J'ai donc un premier utilisateur qui s'inscrit à 13h57, statut "accepté".
- J'ai ensuite l'inscription de 2 utilisateurs simultanés, à 14h01 (et 13 secondes exactement). Les deux obtiennent le statut "accepté" d'office alors que l'un d'eux aurait dû être sur file d'attente.
Les requêtes de vérification ayant lieu à la même seconde, tout était correct à ce moment précis...
Mais voilà, j'ai 3 personnes dont le statut est "accepté" au lieu de 2...


Je précise que le système a toujours bien fonctionné jusque là, donc pour moi, aucun problème de code, tout a été vérifié. Sauf que là, c'est un cas bien particulier.

Auriez-vous une idée qui expliquerait cela?
Merci d'avance.

[Exia_]

Bonjour,

comment gère tu la vérification du nombre d'utilisateur étant accépté ?

De manière applicative ou une contrainte dans le SGBDR ?

[gazelle]

Bonjour,

Voici comment ça se passe d'un point de vue algo :
Dans ma table "évènement", j'ai un champs "statut_evt" qui définit quel statut les personnes auront à l'inscription (ce champs peut paraître inutile, mais j'en ai besoin).
Donc à la création d'un évènement, le statut par défaut est "accepté" :
statut_evt = accepte;

Tant que je n'ai pas atteint mon quota, ce statut ne change pas.

Quand une personne s'inscrit, je vérifie "statut_evt" et ensuite, je vérifie si son inscription atteindra le quota. Si c'est le cas, je change le statut de l'évènement :
"statut_evt" = "file d'attente",
puis j'inscrit mon utilisateur qui aura le statut "accepté".

Donc le prochain utilisateur aura le statut "file d'attente" (selon le champs de ma table "évènement" : "statut_evt").

Je ne sais pas si j'ai été assez claire...

[CinePhil]

Quand une personne s'inscrit, je vérifie "statut_evt"

Par une requête ?

ensuite, je vérifie si son inscription atteindra le quota.

Par une autre requête ?

Si c'est le cas, je change le statut de l'évènement :
"statut_evt" = "file d'attente",

Donc une autre requête !

j'inscrit mon utilisateur qui aura le statut "accepté".

Et encore une requête.

Entre temps, un autre utilisateur est venu s'inscrire avant que la requête de changement de statut n'ait eu lieu.

Tu devrais passer par une procédure SQL qui permettra de faire toutes les opérations en une seule transaction et en verrouillant les tables et le second utilisateur attendra que la première inscription soit terminée. Rassure-toi, ça va très vite et l'utilisateur physique derrière son écran ne sentira pas la différence.

[gazelle]

Merci CinePhil pour cette réponse, c'est un peu près ça à une requête près.
Je pense faire ça avec une transaction géré en PHP, car j'ai pas mal de condition intercalé entre mes différentes requêtes.
Est-ce que ça fonctionnera? (je n'ai jamais fait de transaction dans ma vie de développeur)

[ericd69]

salut,

la procédure stockée va te permettre d'encapsuler en elle toute la logique de décision et les requêtes, ça évite les allers-retours php/mysql et c'est plus facile à maintenir

les transactions ça n'a de sens qu'avec des tables en innodb sinon tu devras faire des lock/unlock mais eux sont sur une table entière... après il y a plusieurs niveau d'isolation dans les transactions, faut voir celui qui convient le mieux et ça dépend de comment tu gères justement le suivi... tu écriras des transaction plus efficacement dans une procédure et ça limitera beaucoup les risques de blocage de tables...

[redoran]

Salut ; + de ce qui est dit et pour plus d’équité le tous ce joue sur le temps d'inscription soit pour statut accepter ou liste d'attente.

[gazelle]

Merci à tous pour vos réponses, j'y vois un peu plus claire dorénavant.
Je ne savais pas quoi utiliser entre les procédures stockées ou les transactions.

Je me suis donc lancée dans les transactions avec l'isolation sur "serializable".
D'après ce que j'ai compris, il verrouille uniquement les lignes concernées (dites moi si je me trompe). Donc pas de lock/unlock sur les tables entières.

Par contre, je n'arrive même pas à reproduire le bug de base à l'aide de requête ajax asynchrone...
Si je rajoute les transactions, je vois bien le comportement attendu dans les logs mysql mais, je ne vais pas pouvoir vérifier que le bug ne se reproduira plus...

[ericd69]

c'est ça...

serializable est en effet ce qui est le mieux pour ce que tu veux faire je pense

mais l'idéal est d'utiliser les 2 biensur, procédure et transaction... en plus tu peux faire un gestionnaire d'erreur qui va juste faire un rollback au lieu de générer l'erreur et faire un rollback (un peu comme un try ... catch) genre:

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

declare continue handler for sqlexception rollback;

tu peux aussi mettre un bloc de code, encadré par

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

 begin ... end;

dans le handler pour faire des actions plus compliquées genre la gestion d'un log d'erreur, etc...