T
tuxedo
Gast
Hallo zusammen,
bisher hatte ich immer nur eine Anwendung die auf eine DB zugegriffen hat. Da war es noch recht easy, aber nun geht es um folgendes:
Wir haben 3 Anwendungen auf einer Maschine (eine Serveranwendung, eine Konsolenanwendung, sowie eine C++ Anwendung), welche Daten in mehrere Tabellen eines PostgreSQL einfügen und auch bearbeiten.
Das ganze ist ein über mehr als 10 Jahre gewachsenes System und nicht wirklich einfach zu durchschauen. Aktuell haben wir das Problem, dass wenn die Maschine gut ausgelastet ist und es viele Daten zu verarbeiten gilt, die Datenbank sehr oft (rund 160x am Tag, für uns ist das sehr oft) in ein Deadlock läuft:
Postgres schieß dann einen der beiden Prozesse ab, welcher dann ein Rollback fährt und die Geschichte geht in einem neuen Versuch von vorne los.
Alle Aktionen auf der Datenbank laufen innerhalb von Transactions. Meine bisherige Analyse:
Prozess A aktualisiert Datensatz 1
Prozess B aktualisert Datensatz 2
Prozess B aktualisert Datensatz 1
-> B wartet nun bis A seine Transaktion abgeschlossen hat und 1 freigibt
Prozess A aktualisiert 2
-> A wartet nun bis B seine Transaktion abgeschlossen hat und 2 freigibt
Da sich die Reihenfolge der Updates nur schwer festlegen lässt (hängt davon ab was über's Netzwerk für Anfragen eingehen), und es unter Umständen von der C++ Anwendung dutzende Instanzen geben kann (das variiert), lässt sich das nur schwer lösen.
So wie ich das sehe, wird wohl ein größerer Umbau anstehen....
Meine Frage nun:
Wenn man so eine Konstellation hat, wo tatsächlich mehrere Programme auf ein und dieselbe Tabelle einer DB zugreifen und Daten einfügen/ändern müssen: Gibt's da irgendwelche Best-Practice Regeln oder Vorgehensweisen?
* Ein Punkt hab ich bereits gefunden: Aktionen nach Möglichkeit immer in derselben Reihenfolge ausführen.
Mehr hab ich noch nicht gefunden. Onkel Google lässt sich dazu nur schwer befragen, da dies irgendwie schon "etwas spezielles" ist. Und einfach die ganze Tabelle 'locken' wenn jemand was drauf tut könnte die Performance wohl noch weiter in die Knie zwingen.
- Alex
bisher hatte ich immer nur eine Anwendung die auf eine DB zugegriffen hat. Da war es noch recht easy, aber nun geht es um folgendes:
Wir haben 3 Anwendungen auf einer Maschine (eine Serveranwendung, eine Konsolenanwendung, sowie eine C++ Anwendung), welche Daten in mehrere Tabellen eines PostgreSQL einfügen und auch bearbeiten.
Das ganze ist ein über mehr als 10 Jahre gewachsenes System und nicht wirklich einfach zu durchschauen. Aktuell haben wir das Problem, dass wenn die Maschine gut ausgelastet ist und es viele Daten zu verarbeiten gilt, die Datenbank sehr oft (rund 160x am Tag, für uns ist das sehr oft) in ein Deadlock läuft:
Process 20066 waits for ShareLock on transaction 199566375; blocked by process 24520.
Process 24520 waits for ShareLock on transaction 199566378; blocked by process 20066.
Postgres schieß dann einen der beiden Prozesse ab, welcher dann ein Rollback fährt und die Geschichte geht in einem neuen Versuch von vorne los.
Alle Aktionen auf der Datenbank laufen innerhalb von Transactions. Meine bisherige Analyse:
Prozess A aktualisiert Datensatz 1
Prozess B aktualisert Datensatz 2
Prozess B aktualisert Datensatz 1
-> B wartet nun bis A seine Transaktion abgeschlossen hat und 1 freigibt
Prozess A aktualisiert 2
-> A wartet nun bis B seine Transaktion abgeschlossen hat und 2 freigibt
Da sich die Reihenfolge der Updates nur schwer festlegen lässt (hängt davon ab was über's Netzwerk für Anfragen eingehen), und es unter Umständen von der C++ Anwendung dutzende Instanzen geben kann (das variiert), lässt sich das nur schwer lösen.
So wie ich das sehe, wird wohl ein größerer Umbau anstehen....
Meine Frage nun:
Wenn man so eine Konstellation hat, wo tatsächlich mehrere Programme auf ein und dieselbe Tabelle einer DB zugreifen und Daten einfügen/ändern müssen: Gibt's da irgendwelche Best-Practice Regeln oder Vorgehensweisen?
* Ein Punkt hab ich bereits gefunden: Aktionen nach Möglichkeit immer in derselben Reihenfolge ausführen.
Mehr hab ich noch nicht gefunden. Onkel Google lässt sich dazu nur schwer befragen, da dies irgendwie schon "etwas spezielles" ist. Und einfach die ganze Tabelle 'locken' wenn jemand was drauf tut könnte die Performance wohl noch weiter in die Knie zwingen.
- Alex