Herausfinden, ob ein Datensatz gesperrt ist und welcher User den Satz sperrt

[BenderD]

Tut mir leid, aber ich kann nicht nachvollziehen, wieso eine Implementierung besser ist, die einem User das Editieren eines Datensatzes erlaubt, ohne dass sie sicherstellen kann, dass er das dann später auch speichern kann. Ein Rollback räumt doch nur auf. Der User, dessen Änderungen nicht gespeichert werden können, hat davon erstmal nichts.

Dieter

... habe ich nie behauptet. Länger andauernde Sperren werden logisch gesetzt (siehe Baldurs Ausführungen). Wenn ich das unter Commit mache, verschwinden die mit einem automatischen Rollback, wenn das Programm abschmiert. Programmiere ich in der Oberliga, kann ich über ein Notify Object oder eine Transaction Monitor wie CICS (was ist das denn schon wieder?) den Benutzer der abgeschmierten Session bei Wiederanmeldung das wieder anbieten (so ähnlich wie bei abgeschmierten Editor Sitzungen).

D*B

[BenderD]

Ich halte physische Sperren für sicherer, weil dann auch Zugriffe per SQL verhindert werden.

... wenn man natürlich den Empfehlungen mancher hier folgt und bei SQL mit commit level *NONE arbeitet, dann ist Hopfen und Malz verloren...

Mal ganz abgesehen davon, dass das mit dem API nicht funktioniert:
- gucken mit API, keine Sperre da
- rein in die Verarbeitung: Mist geht doch nicht, ein anderer war schneller 60 sec. blockiert
oder:
- gucken mit API, Sperre da Benutzre XYZ
- den angerufen, der ist aber längst fertig, aber ein anderer hat jetzt angefangen
... vielleicht gut fürs Betriebsklima, da reden Leute wenigstens miteinander...

D*B

[dschroeder]

Wenn ich Sperrungen nur logisch setze, würde ein manuell abgesetztes SQL (z.B. aus dem Navigator heraus) das ja nicht bemerken. Ich müsste dann auch noch bei jedem SQL unsere logische Sperre mitselektieren. Bei physischen Sperren kann ich das jedoch einfach in einer where Klausel machen.
Dieter

[Robi]

Wir machen ähnlich der von Dieter beschriebenen Methode. Nur das wir selten Views lesen

Je PF, je LF fällt ein Lesepgm (u.v.m) aus unserem Generator
(unsere Lese Pgmme können auch schreiben, das ist performanter)
Jeglicher Dateizugriff MUß über diese Pgmme erfolgen.
Fehlersuche damit recht einfach, debug, breakpoint setzen warten und stapel ansehen
Sperre händling:
- Weiche Sperren,
-- Sind diese gewünscht : update des Satzes mit Jobnr in ein Feld,
ist Jobnr belegt, dann Satz gesperrt --> Job-Info an den rufenden job

- Harte sperren
-- nur wenn eine Nr sich hochzählt. Das machen die Pgmme alleine
(über automatich eingebundene /copy via Namensregel)

Dazu SEU Erweiterungen die den nötigen code zum lesen / Schreiben / fehlerhändlichg eingenerieren. Diese sehr komfortablen SEU-Erweitrungrn sind der Grund das wir noch nicht mit RDI (o.wie das grade heist) arbeiten

viel Erfolg!
Robi

[Robi]

Wenn ich Sperrungen nur logisch setze, würde ein manuell abgesetztes SQL (z.B. aus dem Navigator heraus) das ja nicht bemerken. Ich müsste dann auch noch bei jedem SQL unsere logische Sperre mitselektieren. Bei physischen Sperren kann ich das jedoch einfach in einer where Klausel machen.
Dieter

Uns wurde vor gefühlten 100 Jahren schon beigebracht:
Wenn Zugriffe auf die Daten außerhalb der WaWi (heute ERP) nötig sind ist die WaWi mist!

Das können wir zwar nicht immer einhalten, finde die Grundidee abr klasse!
Was sprich gegen ein "and XXXjobnr = 0" in allen SQL's?

[B.Hauser]

Wenn die Transaktion (also mehrere Updates etc unter Commit läuft) kommt und der Satz unter commit gesperrt ist, kann niemand und nichts außerhalb der Transaktion den Satz oder die gelockten Sätze ändern, weder SQL noch native I/O noch updta, noch was auch immer. Abhängig vom Commitment level können u.U. geänderte und neu geschriebene Datensätze "gesehen" bzw. gelesen werden.

Einen Satz zu sperren und so lange gesperrt zu halten bis die Änderungen "eingegeben" sind, mag ja bei klassischen Green Srceen-Anwendungen funktionieren, .... versuch das gleiche mal in einer Web-Anwendung (Stichwort stateless!)

Wenn Du entsprechende Update-Module wie Dieter vorgeschlagen hat generierst, kannst Du u.U. auch einen Abgleich (ursprünglicher Satz, geänderter Satz, aktueller Satz) auf Feld-Ebene integrieren und die aktuellen Daten so anpassen, d.h.
Original = Änderung = Aktuell --> Feld bleibt
Original <> Änderung und Aktuell = Original --> Änderung
Orginal = Änderung jedoch ungleich Aktuell --> Aktuell
Original <> Änderung <> Aktuell --> Änderung

Damit können "Update"-Probleme auf ein Minimum reduziert werden.

Das ist zwar liebevolle Kleinarbeit, wird jedoch pro Datei/Tabelle nur einmalig kodiert und für alle Änderungen in der Datei verwendet.

Birgitta

[BenderD]

Wenn ich Sperrungen nur logisch setze, würde ein manuell abgesetztes SQL (z.B. aus dem Navigator heraus) das ja nicht bemerken. Ich müsste dann auch noch bei jedem SQL unsere logische Sperre mitselektieren. Bei physischen Sperren kann ich das jedoch einfach in einer where Klausel machen.
Dieter

... auch hier heißt das Zauberwort: View Layer (auf das Physical Layer darf per SQL default keiner drauf).

[dschroeder]

Hier im Hause sprechen wir natürlich im Moment nur über statefull Anwendungen. Wenn ich Birgitta richtig verstehe, kann es bei Verwendung von Commit Control und physischen Sperrungen zu nicht auflösbaren Deadlocks kommen? Das wäre natürlich in der Tat ein echtes Argument gegen physische Sperren.
Die Sache mit dem feldweisen Vergleich ist mir noch ein wenig suspekt. Wenn 2 user gleichzeitig verschiedene Felder im gleichen Datensatz ändern und ich das dann feststelle und (da es ja keine Konflikte gibt), die Feldänderungen beider user speichere, heißt das ja noch lange nciht, dass der so aktualisierte Datensatz dann noch logisch in Ordnung ist! Die Anwendung hätte ja vielleicht verhindert, dass die Feldänderung von User 2 gemacht werden, wenn sie gewusst hätte, welche Felder User 1 geändert hat.

Dieter

[BenderD]

Wenn ich Birgitta richtig verstehe, kann es bei Verwendung von Commit Control und physischen Sperrungen zu nicht auflösbaren Deadlocks kommen?

... auch Deadlocks sind bei richtiger Vorgehensweise vermeidbar: Transaktionen müssen ihre Ressourcen in festgelegter Reihenfolge holen (siehe auch dining philosophers problem).

D*B

[dschroeder]

Uns wurde vor gefühlten 100 Jahren schon beigebracht:
Wenn Zugriffe auf die Daten außerhalb der WaWi (heute ERP) nötig sind ist die WaWi mist!

Das können wir zwar nicht immer einhalten, finde die Grundidee abr klasse!
Was sprich gegen ein "and XXXjobnr = 0" in allen SQL's?

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

[BenderD]

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

[malzusrex]

... wenn man natürlich den Empfehlungen mancher hier folgt und bei SQL mit commit level *NONE arbeitet, dann ist Hopfen und Malz verloren...

hmm, ich kann doch nix dafür...

Gruß
Ronald Malz