Transaktionsverarbeitung mit PHP und MySQL

Question

Ich versuche, zweiphasige Commit mit PHP und MySQL zu implementieren und kurz zu kommen.

Der Hauptblock, den ich gefunden habe, ist, dass ich die MySQL -Verbindungsressource nicht an einem Ort speichern kann, an dem ich sie für die zweite Phase wieder finden kann. Ist es möglich, einen Datenbankgriff zu serialisieren?

Hier ist der Fall, für den ich versuche zu codieren:

1. Der Benutzer sendet Daten
2. Der Server startet eine MySQL -Transaktion und führt einige Abfragen aus, die auf den empfangenen Daten basieren.
3. Der Server sendet eine Datei an den Benutzer zurück
4. Wenn der Benutzer die Datei erfolgreich empfangen hat, begeht der Server seine Transaktion. Ansonsten rollt es es zurück.

Dies scheint zwei HTTP-Anforderungs-/Antwortzyklen zu erfordern, daher muss ich in der zweiten Anfrage wieder mit demselben Datenbankhandle zusammenarbeiten können, um die Transaktion zu begehen. Ich habe in diesem Teil versagt.

Jeder Rat ist willkommen, auch wenn es "das ist in PHP nicht möglich".

Answer 1

Schauen Sie sich den LIXA -Transaktionsmanager (http://lixa.sourceforge.net/) an, der PHP und MySQL beginnt, beginnend mit Release 0.9.0

Es bietet eine verteilte Transaktionsverarbeitung und zwei Phasen -Commit -Funktionen.

Grüße

CH. F.

Answer 2

Da PHP die Anforderung / Antwort basiert, ist die Implementierung einer persistenten DB -Verbindung nicht möglich, AFAIK.

Sie könnten versuchen, diese Einschränkung mit einem Ticketing -Mechanismus zu umgehen. Ihre Schritte wären:

1. Der Benutzer sendet Daten
2. Der Server startet eine MySQL -Transaktion und führt einige Abfragen aus, die auf den empfangenen Daten basieren, wobei dieser Transaktion ein "eindeutiges" Ticket zugewiesen wird.
3. Der Server sendet eine Datei und das Ticket zurück an den Benutzer
4. Wenn der Benutzer die Datei erfolgreich empfangen und eine andere Anfrage mit diesem Ticket gesendet hat, verpflichtet der Server seine Transaktion. Ansonsten rollt es es zurück.
5. In Bezug auf Cassys Kommentar: Nach einem bestimmten Zeitraum sollten alle TAs nicht verpflichtet werden, um zu verhindern, dass Ihr DB mit alten Transaktionen „überflutet“ ist

HTH

Answer 3

Um KB22 und Rojoca zu beantworten, ist der Grund, warum ich es so tun muss, dass die "Datei", auf die ich mich beziehe, tatsächlich eine SQLite -Datenbank ist, die als Datenspeicher auf einem mobilen Gerät endet.

Die erste Anfrage veröffentlicht die aktualisierte SQLite -Datenbank an den Server, in dem versucht wird, Daten aus den SQLite -Tabellen zu verschmelzen. Probleme treten auf, wenn das mobile Gerät keine neue SQLite -Datenbank (eine, die die Änderungen des mobilen Geräts und alle anderen neuen Dinge aus der Webanwendung widerspiegelt) nicht erfolgreich empfängt), da es dann versucht, dieselbe (alte) SQLite -Datenbank an die zu senden Web ein zweites Mal, was zu doppelten Einträgen in den Webtabellen für alles führt, was auf dem mobilen Gerät erstellt wurde.

Daher muss das Web sicher sein, dass das Gerät die neue Datenbank hat, bevor sie die Zusammenführungsänderungen begehen. Angesichts der Launen von Netzwerken erscheint dies nur machbar, wenn das Gerät nach Erhalt der neuen SQLite -Datenbank einen expliziten ACK senden kann. Und dies ist nur möglich, wenn wir zwei Anfragen stellen (1. Die SQLite -Datenbank zum Zusammenführen; 2. Der Eingang der neuen SQLite -Datenbank auf dem Gerät).

Ein dorniges Problem in der Tat, und es ist nützliche Informationen, um herauszufinden, dass PHP die Datenbank nicht auf die erforderliche Ebene bewegt.

Ich glaube auch nicht, dass ich eine Transaktionstabelle verwenden kann, da ich Daten basierend auf den "realen" Webdatenbanktabellen an das Gerät zurückgeben muss. Ich denke, ich würde auf Probleme mit auto_increment -Feldern stoßen, wenn ich die echten Tabellen nicht verwendet habe.

Danke für all deine Kommentare.