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

[dschroeder]

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

[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

[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

[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

[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

[BenderD]

... aber hoffentlich dagegen!
D*B

... und bei Kraut und Rüben hätte dann wohl der Herr Rübenscheid protestiert ...

[dschroeder]

Vielen Dank an euch alle!
Es hat sich ja eine interessante Diskussion entwickelt. Wir werden die gelieferten Erkenntnisse hier im Haus diskutieren und mal sehen, was wir da machen. Wir haben hier ein bestehendes, gewachsenes System, das wir natürlich nicht von Grund auf neu durchstylen können. Wir müssen deshalb Lösungen finden, die bei neuen Programmen und Programmerweiterungen besser sind als die alten Sperrverfahren. Aber trotzdem müssen wir kompatibel bleiben.

Nochmals vielen Dank.
Dieter

[Fuerchau]

Genau diese Kompatibilität ist ja ein Problem.
Arbeitet die alte Anwendung ohne Journalisierung kann man sie nicht oder nur unter größten Schwierigkeiten darauf umstellen.
Dies habe ich auch schon festgestellt.
Das betrifft dann ebenso die Sperrverfahren solange man ja an die alten Dateien auch dranmuss (was ja schon vorkommen soll).
Für neue Dateien und losgelöste Erweiterungen sollte man durchaus auf Journale und Commit zurückgreifen um es eben besser zu machen, wobei gerade das "Besser" sehr unterschiedliche betrachtet wird.
Spätestens wenn man alt und neu mischen muss fangen die Probleme erst richtig an.
Hier muss man sich dann Konstrukte über getrennte ACTGRP's einfallen lassen damit es funktioniert.
Bei ODBC/JDBC geht das wieder nicht innerhalb einer Verbindung (SQL kann erst mal nur 1 ACTGRP), hier benötigt man dann 2 Verbindungen und Framework-Methoden (Offline Resultsets) sowie Connection-Pools bleiben dann erst mal außen vor.

Wir haben vor ein paar Jahren mal ein paar wenige Dateien einer Anwendung journalisiert ohne Commit zu aktivieren. Das Ergebnis war 10GB / Stunde an Journalen neben ein paar Performanceeinbußen!

[BenderD]

Wir haben vor ein paar Jahren mal ein paar wenige Dateien einer Anwendung journalisiert ohne Commit zu aktivieren. Das Ergebnis war 10GB / Stunde an Journalen neben ein paar Performanceeinbußen!

Das müssen aber dann Dateien mit riesigem Transaktionsvolumen gewesen sein und die Platten extrem langsam. Ich habe vor circa 20 Jahren angefangen nach Möglichkeit alle Dateien zu journalisieren (wg. Nachvollziehbarkeit und effektiver Fehleranalyse). Die Performance Auswirkungen waren stets kaum messbar und in der Tendenz wurde es eher minimal schneller (Die Datenbank schreibt die sequentiellen Journale forciert und die Dateien, wenn es ihr langweilig ist). Solche Horrorstories machen immer wieder die Runde, sind aber in den meisten Fällen nicht verifizierbar.
Ich kann nur empfehlen das auszuprobieren und zu messen. Journalisierung hat man in einer Stunde eingerichtet und in 10 Minuten deaktiviert - und an den laufenden Anwendungen ist kein Änderungsbedarf, die merken das nicht einmal!

D*B