Firebird:deadlock - update conflicts with concurrent update

[Gruber_Hans_12345]

Ich verwende IBX mit Firebird 1.5 und alles läuft (lief) problemlos.
Jetzt habe ich das Problem, da mehrere User gelichzeitig arbeiten, das ich öfters (mehrmals am Tag) einen deadlock bekomme.

Mir ist klar warum der deadlock kommt, und dagegen werde ich auch nix machen können (da es ja in der Natur der Datenbank liegt)

Ich werde zwar probieren die Transactionen zu verkürzen, (also immer wieder zwischendurch ein CommitRetaining machen) aber als 100% Lösung passt es trotzdem nicht.

Wie kann man solche Deadlocks am besten "umschiffen" ?

Bei 95% der Deadlocks bzw. UPDATE's könnte man einfach sagen, das sich diese UPDATES gar nicht gegenseitig behindern (User 1 ändert Feld A und User 2 nur Feld B) und trotzdem kommt ein deadlock, also würde ein zweites mal Update mit den selben daten reichen.
Oder das zweite Update ist das, das wichtiger ist.

Die restlichen 5% müssten zuvor wieder aus der Datenbank ausgelesen werden und erneut entscheidungen getroffen werden (nur Programmintern - keine Userentscheidung)

Gibt es Codefragemente wie man das mit IBX lösen kann ?
Ist es besser JETZT umzusteigen auf andere Komponenten IBO oder UIB oder ... (da diese eventuell besseres Transaction Handling haben ?)

Oder gibt es noch andere bessere Ansätze ...

bin für alle Vorschläge offen

[Jasocul]

Die Einfachste und Beste (imho) Möglichkeit ist, die Lock-Zeit so kurz wie möglich zu halten.
Das erfordert aber etwas mehr Aufwand bei der Programmierung:
Datensatz einlesen und nicht locken (Keine DB-sensitiven Felder verwenden!).
Jetzigen DS-Inhalt merken.
Änderungen durchführen (Off-Line).
Den Datensatz aktuell nochmal holen und vergleichen, ob er sich geändert hat.
Hat sich geändert -> Daten können nicht geschrieben werden, da DS sich geändert hat.
Keine Änderung -> eigene Änderungen können gespeichert werden.

Du kannst natürlich auch den Datensatz zum Lesen sperren, solange er für einen Vorgang benötigt wird. Ob das eine gute Lösung ist, glaube ich nicht.

[Gruber_Hans_12345]

Es handlet sich hier nicht um Eingabewerte von einem Bneutzer sondern um interne Funktionen, die UPDATE Anweisungen in die Datenbank schreiben (also nicht auf einen Benutzer warten oder sonstiges).
Nur habe ich das Problem, wenn viele Leute gleichzeitig Änderungen machen Die Transactionen auch noch so kurz sein können, es sich immer wieder mal ausgeht, das sich ein deadlock ergibt.

Das ganze Programm ist so aufgebaut :
Beim Datenladen wir deine Transaktion werzeugt und die Daten geladen die Transaktion geschlossen und dann in TEdit oder TTrees oder sonsitgen angezeigt.
Wenn gespeichert werden soll, wird eine Transaktion erzeugt und eine TIBQuery mit den Parametern befüllt und dann Commit und Tranasktion geschlossen.

Das ist zu 100% überall so gelöst, also sind die Transaktionen von haus aus schon sehr kurz.

Nur ab und zu geht sich der Deadlock trotzdem aus, oder es werden mehrere Datensätze auf einmal upgedated

[Jasocul]

Beim Einlesen brauchst du eine Transaction? Normalerweise doch nicht, oder?
Das würde dir schonmal eine DeadLock-Stelle sparen.

Beim Update mehrerer Datensätze würde ich ein Protokoll mitführen, welche Datensätze nicht gepeichert werden konnten wegen der Locks.
Wie du die dann anschließen behandelst ist eine andere Frage, die von vielen Faktoren abhängt.
Damit löst du allerdings nur Lock-Probleme. Ein DeadLock wirst du damit auch nicht lösen können. Diese müssen vom Programm von vornherein unterbunden sein. Die dürfen gar nicht erst entstehen.
Du solltest dein Datenbank-Design und dein Programm dahin gehend nochmal genau prüfen.

Eine generelle Lösung gegen DeadLocks gibt es afaik nicht.

[Gruber_Hans_12345]

Zitat von Jasocul:

Damit löst du allerdings nur Lock-Probleme. Ein DeadLock wirst du damit auch nicht lösen können. Diese müssen vom Programm von vornherein unterbunden sein. Die dürfen gar nicht erst entstehen.
Du solltest dein Datenbank-Design und dein Programm dahin gehend nochmal genau prüfen.

Wie sollte man diesen Fehler von vorneherein unterbinden ? So was kann doch nicht funktionieren oder liege ich da falsch ?


Ein beispiel wie soetwas einfach nachzustellen ist :

SQL-Code:

User1> START TRANSACTION;
User1> UPDATE TABLE1 SET FIELD1 = 9 WHERE ID = 12;
User2> START TRANSACTION
User2> UPDATE TABLE1 SET FIELD2 = 12 WHERE ID = 12;
User2 häng nun so lange, bist User1 ein Commit oder Rollback macht
User1> COMMIT;
User2 "deadlock - update conflicts with concurrent update."
würde User1 ein Rollback machen, wäre alles palleti

In diesem Beispiel, könnte ja ienfach die zweite Anweisung mit einer neuen Transaction erneut ausgeführt werden ...

Und das ist genau der Fall, der bei mir eintritt, da hilft kein redesign der Datenbank oder des Programmes um das zu verhindern (ohne damit auch ein gleichzeitiges arbeiten zu verhindern) Und das Programm kann man insofern ändern, das es den Deadlock abfängt und weitere Sachen macht, und genau das würde mich interessieren, wie das andere machen.

[Jasocul]

Natürlich kann man nicht alle Fehler vorhersehen. Aber schön wäre es schon.

Dein Fall den du beschreibst ist kein DeadLock.
Ein DeadLock funktioniert etwa wie eine "Endlosschleife" (vereinfachtes Beispiel):
Aktion 1 verändert DS 1 (Lock)
dadurch muss auch DS 2 geändert werden, ist aber noch nicht passiert.
Aktion 2 verändert DS 2 (Lock)
Diese veranlasst eine Änderung in DS 1 (LockWait)
Die durch Aktion 1 vernlasste Änderung versucht DS 2 zu sperren (LockWait)

Folge:
Aktion 1 wartet auf Aktion 2 und ungekehrt. Das ist ein DeadLock.
D.h.: Solche Sperren (Lock) können nur durch ihren Tod (Dead) aufgelöst werden.

Bei dir handelt es sich um ein "einfaches" Lock-Problem. Oder du hast dein Problem unvollständig geschildert. DeadLocks müssen vom Programm verhindert werden. Da gibt es keine andere Wahl. Wenn es doch mal passiert, muss das Programm korrigiert werden.

Dein Problem kannst du vermutlich durch eine Einstellung bei FB oder den Zugriffskomponenten beheben. Bei FB bin ich aber nicht der Spezi, kann dir also nicht sagen wo. Aber normalerweise gibt es Einstellungen, die das Verhalten für diesen Fall beeinflussen (z.B.: ignorieren, überschreiben, abbrechen)

Ich persönlich würde die Kontrolle aber nicht aus der Hand geben und im Programm prüfen, ob und welcher Fall vorliegt. Die Vorgehensweise habe ich oben schon beschrieben. Ob die Änderungen durch ein Update-Statement oder durch einen Anwender entsteht, ist dabei nebensächlich.

[Gruber_Hans_12345]

Zitat von Jasocul:

Natürlich kann man nicht alle Fehler vorhersehen. Aber schön wäre es schon.
Dein Fall den du beschreibst ist kein DeadLock.

hmm, schon möglich, nur gibt genau bei diesem Beispiel Firebird diese Fehlermeldung zurück.

Mann kann es ja auch schön in der IBConsole ausprobieren, einfach zwei Transaktionen starten und und zwei Updates, dann kommt genau diese Fehlermeldung "deadlock - update conflicts with concurrent update."

und genau dies ist mein Problem, mir ist schon klar, das ich das per Programm lösen kann, aber das auf die schnelle bei über 2000 Units durchgehen, wür dich mir genre für den Anfang sparen ...

Zitat von Jasocul:

Dein Problem kannst du vermutlich durch eine Einstellung bei FB oder den Zugriffskomponenten beheben. Bei FB bin ich aber nicht der Spezi, kann dir also nicht sagen wo. Aber normalerweise gibt es Einstellungen, die das Verhalten für diesen Fall beeinflussen (z.B.: ignorieren, überschreiben, abbrechen)

Ja genau soetwas würd ich brauchen

Zitat von Jasocul:

Ich persönlich würde die Kontrolle aber nicht aus der Hand geben und im Programm prüfen, ob und welcher Fall vorliegt.

Ist sicher besser aber ob das Zeit/Ergebnis dafürspricht ... ich möchte nur einige knifflige selbst machen, den rest sollte die Komponente oder der Server per Default einfach Überschreiben.

Zitat von Jasocul:

Die Vorgehensweise habe ich oben schon beschrieben. Ob die Änderungen durch ein Update-Statement oder durch einen Anwender entsteht, ist dabei nebensächlich.

Ist klar, das es nebensächlich ist, wollte nur klarstellen, das es mit dem "Lock-Zeit so kurz wie möglich zu halte" nicht wirklich was bringt, da ja keinerlei Useraction zwischen dem öffnen der Transaction in dem Commit liegt.

[Jasocul]

Wäre schon eine Menge Arbeit. Vermutlich wird das Problem aber nicht an jeder Stelle im Programm vorhanden sein.
Na ja. Sei es drum.
Ich habe hier im Moment kein Firebird. Kann also nicht nachschauen. Ich drücke dir die Daumen, dass noch ein FB-Spezi seinen Kommentar hier abgibt. Ich behalte das aber auch im Auge. Wenn ich heute Abend Zeit habe (sieht aber im Moment nicht so aus), versuche ich noch was heraus zu finden.

[Hansa]

Er soll 2 Transaktionen verwenden : eine zum Lesen und eine zum Schreiben. Letztere so kurz wie möglich halten. Eventuell nach jedem Schreiben ein Commit/StartTransaction. Dann herrscht Ruhe. @Jasocul : wie kann ich denn leicht feststellen, ob sich ein Datensatz während der Bearbeitung von woanders her geändert hat ? Vor allem : woher weiß ich, was sich genau geändert hat um gezielt darauf zu reagieren ?

[Gruber_Hans_12345]

Zitat von Hansa:

Er soll 2 Transaktionen verwenden : eine zum Lesen und eine zum Schreiben. Letztere so kurz wie möglich halten. Eventuell nach jedem Schreiben ein Commit/StartTransaction. Dann herrscht Ruhe. @Jasocul : wie kann ich denn leicht feststellen, ob sich ein Datensatz während der Bearbeitung von woanders her geändert hat ? Vor allem : woher weiß ich, was sich genau geändert hat um gezielt darauf zu reagieren ?

Hast du dir den Post durchgelesen ? Nein achso ...

Es hat nichts mit dem Lesen zu tun, nur das Problem, wenn zwei Clients gleichzeit in Update in die selbe Tabelle machen wollen, dann bekommt der zweite Client diesen Fehler.
Und mann kann leider nicht immer nach jedem schreiben ein CommitRetaining machen.