PDO, transactions, LOCK TABLE et LOCK IN SHARE MODE

[php_addict]

merci Sephi-Chan, cela erpond exactement à ma question ;-)
donc on est bien d'accord, plus besoin de LOCK TABLE ? ni de LOCK IN SHARE MODE ou de SELECT FOR UPDATE ?

encore merci

[Sephi-Chan]

En effet. Pas besoin de tout ce bazar !


Sephi-Chan

[Zamentur]

C'est marrant je pensais que les transactions étaient ordonnées et qu'une transaction ne pouvait réussir son commit que si les tables qu'elle a lue n'ont pas été changé?

Du coup çà m'interpelle grandement.

---

Donc, dans ton test à 4 requêtes, tu peux être sûr que tes ensembles de requêtes ont bien été lancées l'un après l'autre.

En fait çà répond à ma question, c'est comme çà que je le voyais.

Donc c'est bien ce que je disais 2 transactions ne peuvent pas avoir lieu en même temps. A moins que j'ai rien compris, ce qui est probable car là je suis pas du tout sur de moi.

[christouphe]

@Sephi: par batch je pensais aux BEGIN...END. Mais tu as raison, je dois confondre.
De ce que je savais, les transaction permettent la cohérence des données. Donc si deux joueurs décident de demander une action à la BDD, elle p^rends les deux ordres, mais les réalise dans leur ordre d'arrivée. C'est bien ça.

[Sephi-Chan]

C'est le cas. Ici, on aura 4 transactions qui vont se suivre sur ce modèle :

Transaction A
- Vérifier le flag : il est à 0 ;
- Faire ce que j'ai à faire ;
- Mettre le flag à 1 ;
- Commit.

Transaction B (puis C, puis D)
- Vérifier le flag : il est à 1 ;
- Ne rien faire d'autre ;
- Commit.


Sephi-Chan

[Zamentur]

Donc en aucun cas on ne peut avoir:

[TA]Vérifier le flag : il est à 0 ;
[TA]Faire ce que j'ai à faire ;
[TA]Mettre le flag à 1 ;
[TB]Vérifier le flag : il est à 0; //le commit A n'ayant pas encore eu lieu
[TA]Commit.
[TB]Faire ce que j'ai à faire ;
[TB]Mettre le flag à 1 ;
[TB]Commit.

?

[php_addict]

on parle bien de plusieurs transaction succeptible d'etre lancées en meme temps? nest ce pas?

exemple:

- il y a un action a resoudre, les donnes sont en base de donnée
- 10 joueurs se connectent au meme moment a la millisecondes pret et lance donc le script de resolution d'action
- grace au transaction+flag l'action n'est resolue qu'une seule fois

[Sephi-Chan]

En effet. Les deux transactions ne pourront pas être croisées : elles s'enchaînent.


Sephi-Chan

[php_addict]

encore un grand merci tout semble fonctionner à present ! (resolution d'action testée en ajax avec 4 navigateurs differents)

reste a tester combien d'actions mon script de resolution d'action peut resoudre sans que cela prenne trop de temps...c'est pas gagné ca, enfin bon...encore merci !

[Ter Rowan]

arg mais ça m'embête cette description

en effet je pensais qu'avec les transactions, on gérait finalement une "queue"

à savoir

transaction A demandée puis transaction B (pendant que A non fini)

se traduit par

transaction A
tant que transaction A, transaction B "attend"
quant commit/rollback de transaction A alors démarrage de transaction B


en effet le système de flag proposé par Sephi est différent :

transaction A demandée puis transaction B (pendant que A non fini)

se traduit par

transaction A (annulation de transaction B)

du coup ça voudrait dire dans le cas que je souhaite qu on réalise une boucle de "je regarde le flag tant que le flag est à 1, une fois à 0 je lance B"

Y a pas plus simple comme mécanique ?