Unlock oder Commit ?

[Marcus Herz]

Hallo
Die Xbase++ Doku ist da unklar. Was kommt zuerst ?
Es macht offensichtlich keinen Unterschied, ich entdecke keinen. Aber trotzdem: welche Reihenfolge ist richtig(er)?

[Martin Altmann]

Moin Marcus,
von der Logik her (um auf der sicheren Seite zu sein): erst commit und dann unlock. Aber macht nicht ein unlock implizit ein commit?

Viele Grüße,
Martin

[Tom]

Und ich sehe das andersherum. Erst wenn der Datensatz freigegeben ist, hat es Sinn, ihn auch durchzuschreiben.

[Martin Altmann]

Die Gefahr ist aber da, das dann bereits jemand anders dran ist - ihn ggf. gelocked hat. Dann kannst Du nicht mehr durchschreiben.

Viele Grüße
Martin

[brandelh]

Und ich sehe das andersherum. Erst wenn der Datensatz freigegeben ist, hat es Sinn, ihn auch durchzuschreiben.

in einer gesharten Datei kann man nicht in einen Datensatz schreiben, der nicht geblockt ist, ich stimme Martin zu.

Ich meine mich zu erinnern, dass unlock erst schreibt, dann freigibt.

COMMIT wirkt übrigens auf alle offenen Dateien

[Tom]

Du kannst ja auch ein DbCommitAll() machen, ohne dass alle Tabellen vollständig gesperrt sind. Es geht nur darum, den Cache physisch durchzuschreiben. Das hat mit den Sperrmechanismen eigentlich überhaupt nichts zu tun; es sollte völlig egal sein, zu welchem Zeitpunkt man das macht. Nur werden Änderungen, die man nach einem Commit vorgenommen hat, erst mit dem nächsten Commit oder dem nächsten impliziten Durchschreiben auf die Platte gesetzt.

[Marcus Herz]

Aber macht nicht ein unlock implizit ein commit?

Da steht nichts dazu in der Hilfe. Wäre anzunehmen.
Ein Unlock ist das Gegenstück zu rlock, egal ob man "replaced" hat.
Ist die Datei exclusiv, ist ein Commit immer nötig/sinnvoll, soweit ich das erkenne, wird sonst erst bei einem Skip geschrieben

@Frank++: Kannst du dazu näheres erläutern?

[Manfred]

die Frage ist evtl. was Marcus erzielen will? Möchte er nur die Reihenfolge wissen, weil er heute wissbegierig ist, oder auch ob und wann wirklich geschrieben wird? Ich meine mich erinnern zu können, das ein Skip(0) am Ende auf jeden Fall schreibt. Es gibt dazu auch einige Beiträge aus alten Zeiten hier im Forum.

[Martin Altmann]

Naja - weder ein Skip noch ein commit schreiben physisch durch auf die Platte. Darum kümmert sich das OS. Die Daten liegen im Cache - und das ggf. noch eine Ewigkeit (zumindest aus der Sicht eines Computers). Für Xbase++ gibt es kein Warten, bis die Daten physisch auf der Platte stehen - das OS meldet erfolgt, hält die Daten aber im Cache. Beim Lesen wird natürlich auch der Cache berücksichtigt, um aktuelle Daten zu erhalten.
Wenn man aber den PC nach einem erfolgreichen Commit ausschaltet, sind die vorher erfolgreich committeten Daten ggf. vergessen.

Viele Grüße
Martin

[Marcus Herz]

Skip(0)

Das liest den Satz neu von der Platte, also genau das Gegenstück zu Commit

[komnick]

Hallo allerseits,

historisch betrachtet käme zuerst UNLOCK und dann COMMIT.
Denn zu Clipper-Zeiten hat man noch zwischen dem Clipper-Puffer und dem DOS-Puffer unterschieden.
Ein UNLOCK (und auch eine Bewegung des Satzzeigers) bewirkte damals die Übergabe des Clipper-Puffers an DOS. Wollte man sicherstellen, dass die Daten aus dem DOS-Puffer auf die Platten geschrieben werden, hat man COMMIT benutzt.
(Quelle: "Das Clipper 5.2 Buch", Sybex)

Beste Grüße
Martin

[Marcus Herz]

Nach einem dbAppend ist ja immer ein dbcommit nötig, kein unlock

[Tom]

kein unlock

APPEND BLANK oder DbAppend() fügen einen leeren Datensatz an und sperren ihn. Wenn Du irgendwie damit weiterarbeiten willst, musst Du ihn durchaus wieder entsperren. Das Verhalten ist das gleiche wie der Sprung zu einem Datensatz und seine Sperre für die Bearbeitung, mit dem Unterschied, dass hier zu einem neuen, leeren Datensatz gesprungen wird.

[brandelh]

kein unlock

Wenn Du irgendwie damit weiterarbeiten willst, musst Du ihn durchaus wieder entsperren.

Also ich speichere erst die neuen Daten in dem Datensatz, bevor ich weiter mache

dbUnlock() reicht aus meiner Erfahrung (solange das Betriebssystem darunter nicht der Meinung ist, Änderungen erstmal zu verbergen),
danach mach ich ein skip(0) um tatsächlich alle Buffer neu zu laden.

[Tom]

Also ich speichere erst die neuen Daten in dem Datensatz, bevor ich weiter mache

Ich habe Marcus' Behauptung widersprochen, dass nach einem DbAppend() kein Unlock nötig wäre. Tatsächlich ist es genauso nötig wie nach der Aktualisierung eines bestehenden Datensatzes, den man zuvor gesperrt hat. Technisch ist's sogar dasselbe, wobei DbAppend() zusätzlich den leeren Datensatz anhängt, den es zu bearbeiten (zu aktualisieren) gilt.

Und "gespeichert" ist's sowieso. Ein FieldPut() bzw. REPLACE ist ein Vorgang, der Daten in einem Datensatz speichert. Das, was vermeintlich durch DbCommit ausgelöst wird, ist das Durchschreiben auf irgendwelche physikalischen Datenträger, aber ich wage tatsächlich zu bezweifeln, dass das im Jahr 2024 immer noch so ist. Ein Commit finalisiert Transaktionen auf einem Datenbankserver, aber wenn wir mit dateibasierten DBMS arbeiten, haben wir überhaupt keinen. Ich halte das genau genommen für überflüssig (obwohl wir's im Code haben, jedenfalls hier und da, aber eher aus den Gründen, aus denen sich Leute Christopherusplaketten ins Auto hängen).

[mikehoffmann]

Auf O/S Ebene hat man durchaus Einfluss darauf, ob ein File gepuffert wird. Da gäbe es zum Beispiel FILE_FLAG_NO_BUFFERING als Würze beim Öffnen einer Datei. Auch das physische Rausschreiben kann man mit FlushFileBuffers erzwingen. Wie weit das physische Schreiben wirklich physisch ist, hat man nicht unbedingt im Griff, denn spätestens wenn die Platte (oder was sich dafür hält) einen Puffer hat, dann kann es zu Staus auf der A3 kommen. Diese pikanten Details stehen einem bei einer DBF aber nicht zur freien Verfügung.
Dass die Caches für Differenzen in den sichtbaren Daten in den DB-Äffchen sorgen, glaube ich nicht. So schlau sind die Fensterchen schon, dass geteilte Dateien durch den selben Cache gefahren werden. So isses auch mit den Dateien im Netzwerk.
Was die Lockerei angeht, so ein Lock ist wie ein kritischer Bereich, in dem man die gelockten Daten verändern darf und es ist sichergestellt, dass alle anderen nach dem Freigeben des Locks die frisch geschriebenen Daten sehen. Das ist mehr oder minder heikel. Wenn ich nur lesend auf der DBF rumeiere ist das ziemlich egal, aber wenn ich durch einen Lock ankündige, etwas zurückschreiben zu wollen, dann muss erst mal neu gelesen werden.

Heißt:
RLock() => Locken, dann nochmal lesen.
UNLOCK: => Schreiben, dann unlocken.

Könnten wir mal ausprobieren, was wirklich passiert. Und vorher Wetten abschließen. Wer verliert, muss einen Vortrag halten und Fragen zulassen.

[Tom]

Wer verliert, muss einen Vortrag halten und Fragen zulassen.

Bis zum "Und" wäre ich dabeigewesen.

[Marcus Herz]

Könnten wir mal ausprobieren,

Das hab ich mir für heute Vormittag vorgenommen. Ich teile die Ergebnisse dann

[Marcus Herz]

die Frage ist evtl. was Marcus erzielen will? Möchte er nur die Reihenfolge wissen, weil er heute wissbegierig ist,

Da hat Manfred schon recht. Im Browser gibt es eine generische Schreibroutine, welche alle Datenbankvarianten abdecken muss:

• DBF

• ADS

• PostgreSQL

• SqlExpress

• ODBC

Meine Test haben jetzt folgende Resultate ergeben:
Xbase+ DBF, shared
-> dbrlock() // Satz in dbrlocklist() sichtbar
-> dbunlock() // wie erwartet, jetzt auch für andere sichtbar
Aber:
-> dbrlock() // Satz in dbrlocklist() sichtbar
-> dbcommit() // Satz wird geschrieben, ist jetzt schon für andere sichtbar, aber immer noch gesperrt
-> dbunlock() // dbrlocklist() leer
Und:
-> dbrlock() // Satz in dbrlocklist() sichtbar
-> dbskip(0) // keine Auswirklung
-> dbunlock() // wie erwartet, jetzt auch für andere sichtbar
Aber:
-> dbrlock() // Satz in dbrlocklist() sichtbar
-> dbskip(1) // wie dbcommit()
-> dbunlock() // dbrlocklist() leer
Xbase+ DBF, exclusiv
dbrlocklist() bleibt leer, weil kein Satz gesperrt wird. dbrlock() gibt aber true zurück:
-> dbunlock() // schreibt satz
oder:
-> dbcommit() // schreibt satz
oder:
-> dbskip(1) // schreibt satz
Aber:
-> dbskip(0) // schreibt satz NICHT

Bei DbAppend() verhält sich Xbase++ DBF genauso. Der neue Satz ist auch in der DbRlocklist()


Ein DbCommit() nach einem dbUnlock() scheint keinen mir sichtbaren Effekt zu haben.


ADS, getestet auf API Ebene, nicht ADSDBE
Hier wir ein Schreibbefehl erwartet. API Funktion AdsWriteRecord, was einem Commit entspricht.
-> AdsLockRecord = DbRlock()
-> AdsWriteRecord() = DbCommit() UND dbUnlock()
-> AdsUnlockRecord() = DbCommit() UND dbUnlock() // es reicht also nur eine von beiden Funktionen aufzurufen
Oder:
-> AdsLockRecord = DbRlock()
-> AdsSkip(1) // schreibt Satz, bleibt gesperrt


Aber:
-> AdsLockRecord = DbRlock()
-> AdsSkip(0) // liest den Satz erneut ein und verwirft Änderungen!.


Bei PostgreSQL, ODBC erfolgt das Schreiben ja über die SQL Befehle und ist in dieer Auflistung nicht relevant.

So stehts übrigens in der Xbase Hilfe

IF RLock()
REPLACE FIELD->LASTNAME WITH cLastName
DbCommit()
DbUnlock()
ELSE
Alert( "Record is locked. Cannot update data", {"Ok"} )
ENDIF

und

DbAppend()
FIELD->CUST_ID := 2006
FIELD->NAME := "CapeHorn"
DbCommit()

[mikehoffmann]

Ich wäre noch eine Etage tiefer eingestiegen, da wo Xbase++ das API bemüht. Nur so sieht man, was wirklich passiert.