[PHP] Transacties met mysql, concurrency risico's?

[m-m]

Stomme vraag, maar ik kan er nergens een eenduidig antwoord op vinden.

Ik heb een (vrij triviaal) stukje functionaliteit toegevoegd aan een vrij ouderwets stukje PHP-code dat gebruikt maakt van een vrij dunne wrappe om de standaard mysql_-functies van PHP. (Dus geen mysqli/pear/pdo/etc).

Nu wou ik dat triviale stukje code van mij graag laten werken dmv. een transactie.

Daartoe heb ik simpelweg het volgende gedaan: eerst doe ik simpelweg "START TRANSACTION;" als query (dus eigenlijk gewoon mysql_query("START TRANSACTION;");). Vervolgens doe ik wat ik moet doen en doe ik vervolgens op dezelfde manier een COMMIT of ROLLBACK.

Alleen gebruikt PHP voor zover ik weet een pool voor haar connecties.

Wat nou als door een of ander kosmisch toeval het volgende gebeurt:

1. 'mijn' apachethread wordt uitgescheduled tussen twee queries in midden in de transactie.
2. een andere wordt ingescheduled en krijgt van de pool 'mijn' SQL-connectie die toch niets aan het doen was en voert een ongerelateerde update/insert query uit.
3. 'mijn' thread krijgt de CPU weer en gaat verder. Er gaat iets mis en mijn thread doet een rollback.

Is de wijziging van de andere thread dan ook ongedaan gemaakt?

PHP is zich niet bewust van de transactie, PHP fungeert in dit geval namelijk enkel als doorgeefluik.

Concreet mijn vragen dus:
- recyclet PHP een mysql_connectie op een dergelijke manier?
- zo ja, houdt het rekening met het openstaan van een transactie somehow?

De manier van werken waarop ik het toevallig ook doe kom ik veelvuldig als advies tegen op internet als ik google, maar nergens uit officiele kanalen dus ik vertrouw er niet op dat het veilig is omdat een boel PHP-programmeurs er niet over nagedacht heeft.

[Voutloos]

Je hoeft je niet druk te maken om andere processen/threads. Connecties worden godzijdank niet op deze grove manier gedeeld.

[m-m]

Gelukkig, dank je. Het leek me ook wat onwaarschijnlijk maar dat is PHP qua gedrag wel op meer vlakken. Dan kan ik mijn code met een gerust hart live gooien

[leuk_he]

Het enige waar je je met pooling druk over moet maken is als het script abort en nooit bij de rollback /commit komt. Die locks die daaruit komen zijn niet fijn.

[WouZz]

Dubbelcheck ook even of je een mysql_connect of mysql_pconnect doet. Die laatste hergebruikt verbindingen namelijk wel, maar wordt weinig gebruikt.

[RobertMe]

Die locks die daaruit komen zijn niet fijn.

Als de connectie naar de MySQL server dicht word gegooid, doet ie automatisch een rollback (but, you'll never know met MySQL)

Houd er ook rekening mee dat transacties in MySQL alleen werken op inoDB tabellen, en als je iets doet op een andere tabel (myisam bv.) krijg je daar geen melding van. In het geval van een rollback, word stilletjes de rollback alleen op de inoDB tabel gedaan, met de andere tabellen gebeurd dus niks (en de data blijft er gewoon in staan, alsof je een commit had gedaan)

[m-m]

WouZz schreef op dinsdag 12 mei 2009 @ 17:50:
Dubbelcheck ook even of je een mysql_connect of mysql_pconnect doet. Die laatste hergebruikt verbindingen namelijk wel, maar wordt weinig gebruikt.

Gebruikt inderdaad gewoon een mysql_connect, dus dat zou goed moeten gaan.

RobertMe schreef op dinsdag 12 mei 2009 @ 18:15:
[...]

Als de connectie naar de MySQL server dicht word gegooid, doet ie automatisch een rollback (but, you'll never know met MySQL)

Houd er ook rekening mee dat transacties in MySQL alleen werken op inoDB tabellen, en als je iets doet op een andere tabel (myisam bv.) krijg je daar geen melding van. In het geval van een rollback, word stilletjes de rollback alleen op de inoDB tabel gedaan, met de andere tabellen gebeurd dus niks (en de data blijft er gewoon in staan, alsof je een commit had gedaan)

Klopt inderdaad, gelukkig is alles innodb. Ook ivm constraints enzo is dat wel zo prettig.