DEADLOCK Problem

Tommy57

Erfahrenes Mitglied
Hallo Leute,

ich stehe vor einem Problem und überlege, wie ich das nun am geschicktesten lösen kann.

Seit mehr als 2 Jahren arbeite ich nun an einer Web-Applikation (PHP/Postgres), wo ich alle Models immer nach dem selben Schema gebaut habe. Hier mal ein Beispiel einer Funktion mit einer Transaktion:

PHP:
public function tuEtwas() {
    try {
        $this->db->beginTransaction();

        [...]

        $this->db->commit();
    }
    catch (Zend_Exception $e) { 
        $this->db->rollback();
        $this->log->alert($e->getTraceAsString());
        return FALSE;
    }
    return TRUE;
}


Nun gehe ich im [...]-Bereich hin und hole mir Datensätze, durchlaufe diese Zeilenweise und ändere irgendeinen Eintrag dazu in der Datenbank. Jetzt kommt es sehr oft vor, dass ich mit dieser Änderung noch weitere Daten ändern muss. Ich bin immer hingegangen und habe in dieser Schleife, welche sich noch innerhalb der Transaktion befindet, einfach noch eine andere Funktion gestartet, welche in einer neuen Transaktion Daten hinzufügt, ändert oder löscht.

Bisher gab es auch nie Probleme, bis gestern Abend. Als ich gestern auf dem Testserver am coden war, habe ich scheinbar einen Deadlock verursacht, der die Datenbank 7 Stunden beschäftigt hat.

Mir wurde damals erklärt, dass ich diese Transaktionen so einbauen soll, aber ich vermute mal, dass das so wie ich es gemacht habe falsch ist. Kann mir vllt Jemand sagen, wie ich es hätte richtig machen sollen und was ich jetzt machen kann, um das Problem zu beseitigen? Die Applikation ist mittlerweile sehr groß. Es würde wahrscheinlich mehrere Tage dauern, alle Funktionen umzuschreiben.

Gruß, Tommy
 
Hallo

Ich kenne Postgres nicht, aber Transaktionen sind an sich immer gleich definiert:
"A transaction is a group of tasks defining a unit of work"
und
"The entire unit must succeed or fail together – no partial completion is permitted"

Stell dir die Frage, ob es Fachlich richtig ist, dass der Funktionsaufruf innerhalb der Transaktion stattfindet. Gehört er immer noch zu dieser unit of work?
Zudem ist es auch so, dass Locks innerhalb einer Transaktion erst am Ende beim Commit/Rollback gelöst werden.
 
Hi BaseBallBatBoy,

streng genommen sind es zwei unterschiedliche Prozesse. Ich werde die beiden mal trennen. ^^
 

Neue Beiträge

Zurück