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

[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