"Ich sperre, also bin ich"

[mfrank]

Hallo,

nachdem ich als Einzelnutzer auf eine Datenbank zugreifen kann, möchte ich einen Mehrnutzerzugriff
ausprobieren. Nach etwas googeln habe ich auch etwas gefunden, was sehr interessant klingt:
"Ich sperre, also bin ich" in Entwickler 2003 Ausgabe 6. Leider gibt es dies nicht mehr nachzubestellen.
Vielleicht kann mir hier jemand weiterhelfen.

Vielen Dank und viele Grüße

Michael

[himitsu]

Was dort drinsteht weiß ich nicht, aber hoika hatte schonmal 2 gute Vorschläge gemacht

http://www.delphipraxis.net/internal...=854092#854092


hier wurde es auch schonmal diskutiert
http://newsgroups.derkeiler.com/Arch.../msg00043.html

[mfrank]

Hallo,

diese Beiträge habe ich schon gefunden - im ersten steht ja auch der Hinweis
auf den "Entwickler".

Michael

[mkinzler]

Wobei bei FireBird dank der Architektur, Sperren oft überflüssig sind.

[alex517]

Hallo Michael,

bevor du anfängst Datensätze zu sperren, solltest du
dich mit der Multi-Generationen-Architektur und dem
Transaktionsmanagement von Firebird vertraut machen.
Wenn du das verstanden hast, wirst du feststellen,
dass Sperren von Datensätzen unter Firebird eher die
Ausnahme bilded als die Regel.
Damit möchte ich nicht behaupten das Sperren nicht
notwendig sind. Aber das Wissen um die MGA und Transaktionen
sind Voraussetzung für den Einsatz von Sperren.

Alex

[mannewolff]

Na ja, Transaktionen helfen ja nicht bei dem Problem der Nebenläufigkeit. Ein Rollback der Datenbank ist außerdem keine Lösung für den Nutzer, nur für die Konsistenz der Datenbank. Optimistischer Lock ist da die Lösung. Es gibt ein Version-Feld in jeder Tabelle. Mit jedem Update wird das Version-Feld um 1 erhöht. Hast Du einen Datensatz mit der Version x dann ist das Update (pseudo code)

Lesen eines Objekts (einer Tabellenspalte)
merken der version in x
..
update tabelle set a=b where version = x;
on error
Benutzer informieren, dass sich Datensatz geändert hat
neuen Datensatz lesen
neuen Datensatz anzeigen

Das Update geht schief, wenn jemand zwischen Lesen und Schreiben etwas geändert hat, weil die Version der Datenbanktabelle dann nicht mehr x sondern >x ist.

[mschaefer]

Moin, moin,

irgendwie findet man bei fast jeder Diskussion zu dem Datensatzsperren den Unsinn,

das 1. "technisches Sperren" für die Datenbankkonsistenz
das 2. "Bearbeitungssperren" für garantiert einmalige Datenversion

vermischt werden. Da der Artikel sich mit dem 2. Problem beschäftigt wäre es sicher
Hilfreich auf die Diskussion über das FB-Versioning hier zu verzichten.


Leider fehlt FB hier eine Abfragemöglichkeit ob ein Datensatz derzeit pessimistisch gesperrt ist. Das wird manchmal mit einem Dummypost auf den zu bearbeitenden Datensatz gelöst. Dabei kracht es nach dem Post oder eben nicht. Hat so eine Tabelle zum Beispiel ein Blob-Feld wird allerdings erst mal mit einer größeren Datenmenge geworfen, was nicht wirklich glücklich ist.

Als Workaround beschreibt
der Artikel die Verwendung einer Sperrtabelle, wobei die Datensatz ID des zu sperrenden Datensatzes in die Tabelle vor Bearbeitung eingetragen wird (könnte auch noch User, Sperrdauer, usw. hinzukommen). Danach wird der Datensatz der Bearbeitungstabelle unter pessimistischem Locking geöffnet und erst nach dem abschließenden Post wird der Eintrag aus der Sperrtabelle genommen. Damit können andere Clients vor Datenzugriff die Sperrtabelle abfragen und einen Datensatz nicht zur Benutzung freigeben. Genaugenommen müssten jetzt wartende Clients noch benachrichtigt werden, dass der Datensatz jetzt verfügbar ist. Dafür war der Artikel aber einige Jahre zu früh unterwegs, heute ist FB da weiter.

Grüße // Martin

[hoika]

Hallo,

Zitat:

könnte auch noch User, Sperrdauer, usw. hinzukommen

Das ist hier noch Wert zu sagen.

Eine Meldung ala "Rechnung Nr. XXX wird gerade von Frau Meier bearbeitet"
ist doch schon sehr anwenderfreundlich.


Heiko