Zitat Zitat von dschroeder Beitrag anzeigen
Erstmal Danke für die Antwort.

Mir wäre es auch lieber, wenn wir nie von außen an die Datenbanken müssten. Leider lässt sich das nicht vermeiden.

Aber zu deinem "Was spricht gegen ein "and XXXjobnr = 0" in allen SQL's?" Da könnte ich genauso gut fragen: Warum baut ihr eine Sperrlogik selber, die die Datenbank doch schon mitbringt? Ihr wollt ja sperren. Sonst würdet ihr ja keine "weichen" oder "harten" Sperren implementieren. Wenn ihr also sperren wollt: Warum wollt ihr dann, dass eine gesetzte Sperre nicht wirkt? Was anderes ist es meiner Meinung ja nicht, wenn einem eine physische Sperre "zu hart" ist. Es kann aus meiner Sicht nur einen Grund geben: Ihr wollt die gesetzte Sperre im Notfall umgehen können. Bei einer "sauberen" Anwendung dürfte das ja nie passieren. Und in einem Notfall könnte ich einen Job (i.d.R eine interaktive Sitzung), der eine physiche Sperre hält, beenden. Dann ist die physische Sperre weg.

Dieter
Es gibt da eine einfache eiserne Regel: Eine Benutzertransaktion klammert immer eine Datenbanktransaktion! Sprich: wenn der Benutzer die Steuerung an das Programm zurückgibt, gibt dieses als erstes alle Satzsperren frei. Wenn ich denn nun länger dauernde Transaktionen habe, komme ich um logische Sperren nicht drumherum (das kann man sich gut an einem Flugreserverungssystem klar machen). Bei Lichte betrachtet gibt es von letzterer Sorte nicht viele Anwendungsfälle, meist steckt da krummes Anwendungsdesign dahinter (siehe Dein Beispiel mit dem Kundensatz!).

D*B