View Full Version : Herausfinden, ob ein Datensatz gesperrt ist und welcher User den Satz sperrt
dschroeder
24-09-14, 16:10
... länger andauernde Bearbeitungen über Record Locks abzubilden ist ein ernsthafter Kunstfehler, da sind andere Implementierungen vorzuziehen. Record Locks sind dafür da Transaktionen abzbilden (siehe auch Commitment Controll).
D*B
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
dschroeder
24-09-14, 16:13
Es gibt da manche Anwendungen die ein bis ein paar Felder in einer Tabelle für logische Sperren vorhalten. Beim Sperren wird User/Workstation eingetragen beim Entsperren wieder gelöscht.
Alle Zugriffe werden über FileHandler durchgeführt, die dann automatisch Sperren prüfen.
Es funktioniert ja auch meistens, allerdings benötigt man dann Reorgs, die verwaiste Sperren wieder aufheben.
Arbeitet man mit Satzsperren ist es natürlich klar, dass diese aufgehoben werden wenn ein anderer Satz über den Handler gelesen wird.
Beim Update wird der Satz im Handler erst noch mal über eine 2. Struktur gelesen und dann der Update durchgeführt. Eine Prüfung, ob sich zwischenzeitlich was geändert hat erfolgt nicht.
Das Ganze System funktioniert, wenn sich alle an die Handler halten.
Was das API angeht so kannst du Satzsperren nach Rel.Satz-Nr. filtern, das geht dann schnell und liefert max. einen Job. Zur Ermittlung der Satz-Nr. benötigst du aber trotzdem einen Chain(N) (N=No Lock) und die Infds.
So einen selbstgebauten Sperrmechanismus haben wir für bestimmte Bereich auch implementiert. Ich würde gerne die von der Datenbank gehaltene "physische" Sperre erkennen.
Ich halte physische Sperren für sicherer, weil dann auch Zugriffe per SQL verhindert werden.
Ich werden mir die APIs mal anschauen.
Vielen Dank an alle.
Dieter
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
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
24-09-14, 16:26
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
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
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?
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
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
24-09-14, 17:01
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