Unlock oder Commit ?

Alle Fragen um die Programmierung, die sich sonst nicht kategorisieren lassen. Von Makro bis Codeblock, von IF bis ENDIF

Moderator: Moderatoren

Antworten
Benutzeravatar
Marcus Herz
1000 working lines a day
1000 working lines a day
Beiträge: 862
Registriert: Mo, 16. Jan 2006 8:13
Wohnort: Allgäu
Hat sich bedankt: 39 Mal
Danksagung erhalten: 197 Mal
Kontaktdaten:

Unlock oder Commit ?

Beitrag von 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)?
Gruß Marcus

Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16555
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 115 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Re: Unlock oder Commit ?

Beitrag von 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
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9391
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 104 Mal
Danksagung erhalten: 363 Mal
Kontaktdaten:

Re: Unlock oder Commit ?

Beitrag von Tom »

Und ich sehe das andersherum. Erst wenn der Datensatz freigegeben ist, hat es Sinn, ihn auch durchzuschreiben.
Herzlich,
Tom
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16555
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 115 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Re: Unlock oder Commit ?

Beitrag von 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
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15703
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 70 Mal
Danksagung erhalten: 34 Mal
Kontaktdaten:

Re: Unlock oder Commit ?

Beitrag von brandelh »

Tom hat geschrieben: Mi, 08. Mai 2024 8:35 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
Gruß
Hubert
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9391
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 104 Mal
Danksagung erhalten: 363 Mal
Kontaktdaten:

Re: Unlock oder Commit ?

Beitrag von 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.
Herzlich,
Tom
Benutzeravatar
Marcus Herz
1000 working lines a day
1000 working lines a day
Beiträge: 862
Registriert: Mo, 16. Jan 2006 8:13
Wohnort: Allgäu
Hat sich bedankt: 39 Mal
Danksagung erhalten: 197 Mal
Kontaktdaten:

Re: Unlock oder Commit ?

Beitrag von 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?
Gruß Marcus

Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
Benutzeravatar
Manfred
Foren-Administrator
Foren-Administrator
Beiträge: 21221
Registriert: Di, 29. Nov 2005 16:58
Wohnort: Kreis Wesel
Hat sich bedankt: 210 Mal
Danksagung erhalten: 67 Mal

Re: Unlock oder Commit ?

Beitrag von 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.
Gruß Manfred
Mitglied der XUG Osnabrück
Schatzmeister des Deutschsprachige Xbase-Entwickler e.V.
großer Fan des Xbaseentwicklerwiki https://wiki.xbaseentwickler.de/index.p ... Hauptseite
Doof kann man sein, man muß sich nur zu helfen wissen!!
Benutzeravatar
Martin Altmann
Foren-Administrator
Foren-Administrator
Beiträge: 16555
Registriert: Fr, 23. Sep 2005 4:58
Wohnort: Berlin
Hat sich bedankt: 115 Mal
Danksagung erhalten: 48 Mal
Kontaktdaten:

Re: Unlock oder Commit ?

Beitrag von 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
:grommit:
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/

Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Benutzeravatar
Marcus Herz
1000 working lines a day
1000 working lines a day
Beiträge: 862
Registriert: Mo, 16. Jan 2006 8:13
Wohnort: Allgäu
Hat sich bedankt: 39 Mal
Danksagung erhalten: 197 Mal
Kontaktdaten:

Re: Unlock oder Commit ?

Beitrag von Marcus Herz »

Skip(0)
Das liest den Satz neu von der Platte, also genau das Gegenstück zu Commit
Gruß Marcus

Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
Benutzeravatar
komnick
UDF-Programmierer
UDF-Programmierer
Beiträge: 76
Registriert: Mi, 04. Jun 2014 9:56
Wohnort: Berlin
Hat sich bedankt: 1 Mal
Danksagung erhalten: 7 Mal

Re: Unlock oder Commit ?

Beitrag von 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
Benutzeravatar
Marcus Herz
1000 working lines a day
1000 working lines a day
Beiträge: 862
Registriert: Mo, 16. Jan 2006 8:13
Wohnort: Allgäu
Hat sich bedankt: 39 Mal
Danksagung erhalten: 197 Mal
Kontaktdaten:

Re: Unlock oder Commit ?

Beitrag von Marcus Herz »

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

Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9391
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 104 Mal
Danksagung erhalten: 363 Mal
Kontaktdaten:

Re: Unlock oder Commit ?

Beitrag von 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.
Herzlich,
Tom
Benutzeravatar
brandelh
Foren-Moderator
Foren-Moderator
Beiträge: 15703
Registriert: Mo, 23. Jan 2006 20:54
Wohnort: Germersheim
Hat sich bedankt: 70 Mal
Danksagung erhalten: 34 Mal
Kontaktdaten:

Re: Unlock oder Commit ?

Beitrag von brandelh »

Tom hat geschrieben: Do, 09. Mai 2024 11:50
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 :wink:

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.
Gruß
Hubert
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9391
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 104 Mal
Danksagung erhalten: 363 Mal
Kontaktdaten:

Re: Unlock oder Commit ?

Beitrag von 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).
Herzlich,
Tom
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 136
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 19 Mal

Re: Unlock oder Commit ?

Beitrag von 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.
Benutzeravatar
Tom
Der Entwickler von "Deep Thought"
Der Entwickler von "Deep Thought"
Beiträge: 9391
Registriert: Do, 22. Sep 2005 23:11
Wohnort: Berlin
Hat sich bedankt: 104 Mal
Danksagung erhalten: 363 Mal
Kontaktdaten:

Re: Unlock oder Commit ?

Beitrag von Tom »

Wer verliert, muss einen Vortrag halten und Fragen zulassen.
Bis zum "Und" wäre ich dabeigewesen. 8)
Herzlich,
Tom
Benutzeravatar
Marcus Herz
1000 working lines a day
1000 working lines a day
Beiträge: 862
Registriert: Mo, 16. Jan 2006 8:13
Wohnort: Allgäu
Hat sich bedankt: 39 Mal
Danksagung erhalten: 197 Mal
Kontaktdaten:

Re: Unlock oder Commit ?

Beitrag von Marcus Herz »

Könnten wir mal ausprobieren,
Das hab ich mir für heute Vormittag vorgenommen. Ich teile die Ergebnisse dann
Gruß Marcus

Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
Benutzeravatar
Marcus Herz
1000 working lines a day
1000 working lines a day
Beiträge: 862
Registriert: Mo, 16. Jan 2006 8:13
Wohnort: Allgäu
Hat sich bedankt: 39 Mal
Danksagung erhalten: 197 Mal
Kontaktdaten:

Re: Unlock oder Commit ?

Beitrag von 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()
Gruß Marcus

Den Kopf in den Sand zu stecken verbessert die Welt auch nicht.
Benutzeravatar
mikehoffmann
Rekursionen-Architekt
Rekursionen-Architekt
Beiträge: 136
Registriert: Mo, 21. Sep 2015 16:22
Hat sich bedankt: 1 Mal
Danksagung erhalten: 19 Mal

Re: Unlock oder Commit ?

Beitrag von mikehoffmann »

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