InterBase: lock conflict on no wait transaction violation of FOREIGN KEY constraint

[mjustin]

Zitat von alex517:

Zitat von mjustin:

Nun wage ich zu folgern (zumindest für InterBase 7.5):

INSERTs in eine Detailtabelle, die per Foreign-Key Constraint mit einer Mastertabelle verknüpft sind, schlagen fehl, wenn am Mastersatz Änderungen gemacht wurden, für die noch kein COMMIT erfolgte

Das muss so sein (ist auch schon immer so),
sonst könntest du dein Detail nicht committen,
da der Master ja mit Rollback wieder verworfen werden könnte.

Das Insert ist im Detail, der Master wird nur in irgendeinem Feld (nicht dem PK) geändert. Daher sollte ein ROLLBACK eines Updates der Mastertabelle kein INSERT im Client blockieren.

Natürlich könnte in der selben Transaktion, die das Update im Master vornimmt, auch ein DELETE des Master-Satzes stattfinden und nach dem COMMIT der Satz für andere Transaktionen unsichtbar werden. Beim Isolationslevel READ COMITTED würde ich aber annehmen, dass erst nach dem COMMIT der Änderungen auf dem Master der Client diese sieht. Also sollte bis zum COMMIT des Masters der Client in der Lage sein ein INSERT auszuführen, da aus seiner Sicht der Master existiert.

Aber immerhin ist nun klar, wie es von InterBase 7 gehandhabt wird.

Der einzige Workaround (ausser dem etwas wackligen "so lange versuchen, bis das INSERT klappt") den ich ausprobieren könnte wäre der Verzicht auf die Foreign Key Constraint in der Detailtabelle. Mich wundert nur, dass dieses Problem nicht öfter beobachtet wird. Vielleicht gibt es zu wenige InterBase Datenbanken, in denen mit Foreign Key Constraint gearbeitet wird. Oder neuere Versionen arbeiten etwas schmerzfreier.

[jobo]

Zitat von mjustin:

Der einzige Workaround (ausser dem etwas wackligen "so lange versuchen, bis das INSERT klappt") den ich ausprobieren könnte wäre der Verzicht auf die Foreign Key Constraint in der Detailtabelle. Mich wundert nur, dass dieses Problem nicht öfter beobachtet wird. Vielleicht gibt es zu wenige InterBase Datenbanken, in denen mit Foreign Key Constraint gearbeitet wird. Oder neuere Versionen arbeiten etwas schmerzfreier.

Damit hättest Du ja alles über Bord geworfen, das den Sinn des Constraint ausmacht.
Ich vermute, dass Constraints relativ wenig genutzt werden, spätestens wegen Problemen wie diesem (oder weil der Entwickler sich noch an sowas erinnert, auch wenn es ein anderes / älteres System war). Hinzu kommt, dass eine fachliche Komponente mitschwingt. Wenn die Software irgendwelche Sachbearbeitung macht und das hängt an einer Vertragsnummer oder Rechnungsnummer oder so, ist ein Konflikt relativ unwahrscheinlich.
Geht es um Produkt oder Bestelldaten, und es wird bspw. die items on stock property häufig geändert, dürften viel mehr solche Fälle auftreten.
Ein filigranerer Sperrmechnismus würde auch helfen. Vielleicht geht es ja bei neueren Versionen.

[mjustin]

Zitat von jobo:

Damit hättest Du ja alles über Bord geworfen, das den Sinn des Constraint ausmacht.

Ja, eine Retry-Schleife ist dem sicher vorzuziehen. Leider sind davon mehrere Anwendungen betroffen, zum Teil laufen die auf Hintergrund-Servern ohne Oberfläche.

[jobo]

Zitat von mjustin:

...snip
Als weitere Absicherung prüft das Programm vor dem INSERT, ob der als FK einzutragende Wert tatsächlich in der MASTER Tabelle "sichtbar" ist (existiert).
...snip

Wie wird denn geprüft, ist das ggF. zu "grob", also entsteht erst dadurch das read lock?
Oder hast Du das bei den Querchecks von vorhin erst gar nicht "nachgeahmt"?

Die Prüfung ist ja doppeltgemoppelt, der FK Constraint soll das ja abfackeln. Besser wäre hier wahrscheinlich, es knallen zu lassen bzw. die database exception zu fangen und zu behandeln (wie auch immer)

[mjustin]

Zitat von jobo:

Zitat von mjustin:

...snip
Als weitere Absicherung prüft das Programm vor dem INSERT, ob der als FK einzutragende Wert tatsächlich in der MASTER Tabelle "sichtbar" ist (existiert).
...snip

Wie wird denn geprüft, ist das ggF. zu "grob", also entsteht erst dadurch das read lock?
Oder hast Du das bei den Querchecks von vorhin erst gar nicht "nachgeahmt"?

Die Prüfung ist ja doppeltgemoppelt, der FK Constraint soll das ja abfackeln. Besser wäre hier wahrscheinlich, es knallen zu lassen bzw. die database exception zu fangen und zu behandeln (wie auch immer)

Ja, die Prüfung kann wieder heraus, sie stammte noch aus der Zeit einige Minuten vor der Aufklärung des Phänomens.

Vielen Dank für die Anregungen und Tips!

[jobo]

Clientseitig ist mir eingefallen, habe ich mal etwas in einem ähnlichen Zusammenhang implementiert, um ähnliche Probleme zu verhindern. Eine Monstermaske mit Master und mehreren Detaildatasets.
Man konnte anfangs einen neuen Mastersatz ungeposted stehen lassen und Details eintragen, bis zum post natürlich, der ging nicht, weil der Masterkey nicht da sein konnte.
Ich habe dann schließlich so umgebaut, dass bei Verlassen (GUI) des Mastersatzes nachgefragt wurde, ob man nicht posten möchte. "Verlassen" kann dabei unterschiedlich komplex sein.

Hilft natürlich nichts, wenn Dein Problem auf unterschiedlichen System basiert. Aber wenn es so ist wie es ist, spricht m.E. auch nichts dagegen, beim Posten (Fehlschlag) eine entsprechende Meldung auszugeben:
"Der .. hat es seit 2h noch nicht geschafft, auf "Commit" zu drücken und blockiert alles, sie finden ihn in Büro xy 2.Etage.. ."

Naja so ähnlich

[hoika]

Hallo,

Zitat:

Vielleicht gibt es zu wenige InterBase Datenbanken, in denen mit Foreign Key Constraint gearbeitet wird.

Zitat:

Oder neuere Versionen arbeiten etwas schmerzfreier.

Hallo, ich denke, zweiteres ist richtig.

Das obige Verhalten hatte ich seit FB1.5 nicht mehr beobachtet.

Allerdings sind bei uns die Mastertabellen immer weit früher gefüllt als die Detailtabellen,
und alles schick mit expliziten Transaktionen gekapselt.

Ein Detail-Datensatz kann per Design bei uns nicht angelegt werden, bis der Master seine Transaktion abgeschlossen hat.
Danach wird auf jeden Fall eine neue (Detail-)Transaktion gestartet.