[PHP/MySQL]Multiple transactions naar verschillende DB's

[Verwijderd]

Ik probeer de beste manier te tackelen om meerdere transaction te starten en te committen bij een totaal positive result.

Wat is het beste, om hier nested try's te gebruiken of zoals onderstaand voorbeeld ?

code:

 // These models are using different connections.
  $c1 = Customer::connection();
  $c2 = AccountingCustomer::connection();
 
  try {
     $c1->transaction();
     $c2->transaction();
     // SQL…
     // SQL…
     // SQL…
     $c1->commit();
     $c2->commit();
 } catch (\Exception $e) {
     $c1->rollback();
     $c2->rollback();
     throw $e;
}

Het lijkt mij mooier om nested te gebruiken omdat je dan al een hele tree welke je wil doorlopen van te voren kunt afkappen met uiteindelijk een exec or whatever in PHP die je wil uitvoeren wanneer alle inserts gedaan kunnen worden.

Iemand een opinie ?

[DJMaze]

$c1->commit(); = true
$c2->commit(); = false

Je kan dan helemaal geen $c1->rollback(); doen. Dus je moet ff totaal wat anders bedenken.

[ Voor 17% gewijzigd door DJMaze op 01-11-2015 19:08 ]

[HMS]

Wat DJMaze zegt klopt, op deze manier kan je niet op de garanties komen die je wil geven. Distributed Transactions is het begrip wat je zoekt. Als ik even snel Google lijkt er wel het een en ander te vinden te zijn voor PHP, maar gezien ik geen PHP dev ben kan ik deze niet op waarde schatten.

Ik hoop in ieder geval dat je nu gerichter kan zoeken.

[Verwijderd]

Ja dat klopt, ik dacht het met if's op te lossen en dan een total commit the doen of a rollback vanaf de if that het mislukt.

Multiple try/catch blocks zou ook moeten werken...

[cariolive23]

Dat kan met een two-phase commit, zie Wikipedia: Two-phase commit protocol Ik weet alleen niet of MySQL dat ondersteunt. Databases zoals Oracle, DB2 en PostgreSQL ondersteunen dit in elk geval wel.

[BlueZero]

DJMaze schreef op zondag 01 november 2015 @ 19:07:
$c1->commit(); = true
$c2->commit(); = false

Je kan dan helemaal geen $c1->rollback(); doen. Dus je moet ff totaal wat anders bedenken.

Volgens mij is dit niet correct de exception wordt al gecatched op het moment dat een van de query's failed.

PHP:

// These models are using different connections.
  $c1 = Customer::connection();
  $c2 = AccountingCustomer::connection();
 
  try {
     $c1->beginTransaction();
     $c2->beginTransaction();
     
     //begin query's
     $c1->query('first query');
     $c1->query('second query');
     $c2->query('third query');
     
     //Als alle bovenstaande code slaagt dan komt php hier terecht, mocht een van bovenstaand failen dan zal php doorverwijzen naar de catch.
     $c1->commit();
     $c2->commit();
 } catch (\Exception $e) {
     $c1->rollback();
     $c2->rollback();
     throw $e;
}

[gekkie]

Referentie van alle queries appenden in een array, bij exception alle referenties in je array rollbacken (want die waren immers geslaagd voordat de exception optrad) ?

(er vanuitgaande dat ze netjes sequentieel afgelopen worden en je geen async geintjes met futures erin gaat stoppen, anders wordt het denk ik racy)

[DJMaze]

BlueZero schreef op dinsdag 03 november 2015 @ 15:44:
Volgens mij is dit niet correct de exception wordt al gecatched op het moment dat een van de query's failed.

En COMMIT kan nooit mislukken?

[gekkie]

Tenzij je connectie eruit vliegt .. maar dan mag ik hopen dat je DB auto rollbackt.
Maar de queries zouden wel kunnen mislukken.

[Janoz]

Wat is dat nu weer voor onzin? Natuurlijk kan een commit mislukken. Sterker nog, dat is juist de plek waar het mis gaat.

@TS, als je daadwerkelijk zulke enterprise dingen wilt gaan doen, dan is het misschien een idee om eens te kijken naar ene iets meer enterprisy omgeving.

[Verwijderd]

Janoz schreef op dinsdag 03 november 2015 @ 23:19:
Wat is dat nu weer voor onzin? Natuurlijk kan een commit mislukken. Sterker nog, dat is juist de plek waar het mis gaat.

@TS, als je daadwerkelijk zulke enterprise dingen wilt gaan doen, dan is het misschien een idee om eens te kijken naar ene iets meer enterprisy omgeving.

Meer enterprisy omgeving ? Ik moet zelf even iets snel in elkaar wrappen op een HA cluster en PHP is niet 200% mijn ding

[Janoz]

Met omgeving bedoel ik meer je toolstack. Als je gedistribueerde transacties nodig hebt dan is een taal die niet verder komt dan een requestscope misschien niet de juiste keuze.

[BlueZero]

Natuurlijk kan een commit mislukken het zei door Resource failure of door tussentijdse wijzigingen waardoor constraints niet kunnen worden voldaan. Echter je kan zelf inschatten hoe groot de kans daarop is denk ik. En wil je het echt zo safe spelen dan heb je altijd nog Two Phase Commits in MySql.

Zie deze link: https://dev.mysql.com/doc/refman/5.7/en/xa.html

[DJMaze]

En dat is in PHP nog steeds experimenteel: http://php.net/manual/en/...start.xa_transactions.php

[Janoz]

BlueZero schreef op woensdag 04 november 2015 @ 12:17:
Natuurlijk kan een commit mislukken het zei door Resource failure of door tussentijdse wijzigingen waardoor constraints niet kunnen worden voldaan. Echter je kan zelf inschatten hoe groot de kans daarop is denk ik. En wil je het echt zo safe spelen dan heb je altijd nog Two Phase Commits in MySql.

Zie deze link: https://dev.mysql.com/doc/refman/5.7/en/xa.html

De reden om transacties te gebruiken is JUIST om dat soort dingen af te vangen. Race condities zijn absoluut geen theoretische mogelijkheden, maar kunnen gewoon in de praktijk voor enorme problemen zorgen. Transacties gebruik je goed, of je gebruikt ze niet. Alles wat er tussenin zit is schijnveiligheid.

Opmerkingen als 'echt zo safe spelen' doet mij vermoeden dat jij het eigenlijk maar overdreven vindt. Als ik een dergelijke houding in één van mijn projectleden tegen zou komen zou hij wat mij betreft per direct op zoek kunnen naar een ander project.

[BlueZero]

Janoz schreef op woensdag 04 november 2015 @ 13:06:
[...]
Opmerkingen als 'echt zo safe spelen' doet mij vermoeden dat jij het eigenlijk maar overdreven vindt. Als ik een dergelijke houding in één van mijn projectleden tegen zou komen zou hij wat mij betreft per direct op zoek kunnen naar een ander project.

Dat vind ik nogal een overtrokken reactie. Ik zeg alleen dat de ontwikkelaar zelf moet bepalen hoe groot hij het risico en de kans acht op een failure.

DJMaze schreef op woensdag 04 november 2015 @ 12:29:
En dat is in PHP nog steeds experimenteel: http://php.net/manual/en/...start.xa_transactions.php

Correct maar je kan de statements wel direct naar de database sturen zonder de geintegreerde PHP functies te gebruiken.

[Janoz]

BlueZero schreef op donderdag 05 november 2015 @ 15:35:
[...]


Dat vind ik nogal een overtrokken reactie. Ik zeg alleen dat de ontwikkelaar zelf moet bepalen hoe groot hij het risico en de kans acht op een failure.

Als je transacties gebruikt, moet je ze goed gebruiken. Als je ze half gebruikt moet je ze niet gebruiken. In dat geval geeft het alleen maar een schijnveiligheid.