PDO, transactions, LOCK TABLE et LOCK IN SHARE MODE

[Sephi-Chan]

Ta première impression est la bonne. Les transactions sont effectuées les unes à la suite des autres.

C'est juste que dans son cas, en emballe un ensemble de requête de transaction pour effectuer une résolution globale (pour plusieurs joueurs) complexe qui n'a besoin que d'être fait une fois. Si on a plusieurs requêtes qui viennent pour la même résolution, c'est chiant. Donc la première qui arrive teste un flag "résolution effectuée". S'il est à false, la résolution s'effectue puis le flag est passé à false. Les autres demandes (qui se sont allés dans la file) effectuent également le test mais échouent (c'est voulu) : la résolution est bien effectuée une seule fois.


Sephi-Chan

[php_addict]

Ta première impression est la bonne. Les transactions sont effectuées les unes à la suite des autres.

C'est juste que dans son cas, en emballe un ensemble de requête de transaction pour effectuer une résolution globale (pour plusieurs joueurs) complexe qui n'a besoin que d'être fait une fois. Si on a plusieurs requêtes qui viennent pour la même résolution, c'est chiant. Donc la première qui arrive teste un flag "résolution effectuée". S'il est à false, la résolution s'effectue puis le flag est passé à false. Les autres demandes (qui se sont allés dans la file) effectuent également le test mais échouent (c'est voulu) : la résolution est bien effectuée une seule fois.

je crois ce que voulais dire Ter Rowan c'est qu'il y a des rollback() inutiles quand plusieurs transaction sont effectuées au meme moment mais que certaine ne sont pas realisées...

mais cela ne semble par etre le cas

dans ma transaction (avec try et catch pour les exeptions), je SELECT tout ce qui a pour flag=0 et je pose un flag=1 des que possible ensuite je manipule des tables et des entrees puis vient le commit()...et d'apres ce que j'ai pu tester il n'y a pas de rollback, les transactions qui echoues sont tout simplement pas realisées

desolé mais Ter Rowan et moi meme semblont avoir du mal à comprendre les transactions:$

[Ter Rowan]

erf pas sur de comprendre ni d etre compris

alors je vais prendre un cas exemple d'achat de magasin

supposons que le processus d'achat soit :
1) SELECT pour savoir si l'objet est disponible, si non échec
2) SELECT pour savoir si l'individu peut acheter l'objet, si non échec
3) UPDATE du stock du magasin ( -1)
4) UPDATE de l'inventaire de la personne ( +1)
5) UPDATE des finances du magasin (+prix)
6) UPDATE des finances de la personne (-prix)

(peu importe si trop de requete, etc.. l'idée c'est d'en avoir plusieurs)

maintenant comment gérer le cas où six personnes lancent en même temps le processus d'achat alors qu'il n'y a en magasin que 3 articles.

si on ne contrôle que le côté unitaire, sans se préoccuper du multi accès
on va avoir 6 fois le contrôle du stock positif (les 6 se connectent, il y a 3 articles pour chacun d'eux)

donc au final, on se retrouve avec stock magasin = -3 et inventaire = +1 pour les six personnes

ma question c'est donc comment gérer ce cas

ce que je comprends du flag de sephi, c'est que 1 et 1 seule des personnes connectés achètera l'objet, les autres étant renvoyés (ie flag pris, merci au revoir, rollback) et que du coup
stock magasin = 2, inventaire personne 1 = 1, inventaire personne 2 3 4 5 6 = 0


voyez ce que je veux dire ?

comment faire pour que personne 1 récupère l'article, que les contrôles du processus de personne 2 constatent qu'il reste des articles et donc que personne 2 récupère l'article, idem personne 3, et que personne 4, pas de chance voit son processus contrôler qu'il n'y a plus de stock ?

[Zamentur]

Ben si j'ai bien suivi et que sephi a dis vrai, on aura jamais -3 articles.

En effet tu contrôles au début si il y a une disponibilité de l'article donc article>0

Et comme les transaction se font les unes après les autres les transactions 4 5 et 6 seront annulé par manque d'article.

Donc en fait ici pas besoin de flag, il s'agit d'un indicateur numérique qui joue ce rôle.

[Sephi-Chan]

+1 Zamentur, c'est bien la quantité de stock qui fait échouer prématurément les transactions qui suivent la première (ou la énième, selon le stock disponible). Du coup tu n'as aucun problème. C'est trop cool les transactions ! \o/


Sephi-Chan

[Ter Rowan]

oki merci beaucoup ^^

c'est cette histoire de flag qui m'a perturbé ^^