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