Hallo dedlfix, > Nehmen wir Inserts. Du brauchst bei der Datenbank kein Locking, um das anfangs dargestellte 4-Punkte-Szenario abzusichern. Du musst keine Sorge haben, dass jemand an die Stelle schreibt, an die du auch gerade schreiben wolltest oder deine Änderungen an der Datei überschreibt. > Natürlich, aber wäre bei flatdb und LOCK_EX ja auch so, oder nicht? > Update ist etwas komplexer, weil der Vorgang sich auf mehrere Requests aufteilt. Da hilft aber kein File-Lock sondern du muss anhand des Datensatzinhaltes feststellen, ob du schreiben möchtest oder nicht, weil sich der Timestamp oder die RowVersion zwischenzeitlich geändert hat. Du machst dann File-Locking zusätzlich zum Concurrency Locking aus Datensicht. Mit der Datenbank hast du zumindest bei Optimistic Locking nur ein Update WHERE RowVersion=alter_wert. Und während in Villarriba … > Da wäre jetzt wieder ein reales Beispiel hilfreich, weil ich nicht erkenne, wie sich das für den blockierten User letztendlich anders auswirken soll. > Und dann haben wir noch nicht mal über Transkationen gesprochen, um komplexe Szenarien mit Beteiligung von mehrern Tabellen so anzusichern, dass bei einem eventuellen Abbruch keine Inkonsistenzen zurückbleiben. > Auch wenn voneinander abhängige Updates auf verschiedene Tabellen erfolgen, wie zb. Reservierungen/Überweisungen/etc…, sind bei Transaktionen alle Anweisungen als eine abzuhandeln, also blockiere alle oder führe alle aus. Da bei einer Flatdb der Schreibprozess ja auch geschützt ist, passiert das gleiche, oder? *edit Ah, stop, wenn es mehrere Textdateien als DB sind, sieht das natürlich anders aus. Ok, aber bei einer einzigen? Gruss Henry

Hallo dedlfix, > Nehmen wir Inserts. Du brauchst bei der Datenbank kein Locking, um das anfangs dargestellte 4-Punkte-Szenario abzusichern. Du musst keine Sorge haben, dass jemand an die Stelle schreibt, an die du auch gerade schreiben wolltest oder deine Änderungen an der Datei überschreibt. > Natürlich, aber wäre bei flatdb und LOCK_EX ja auch so, oder nicht? > Update ist etwas komplexer, weil der Vorgang sich auf mehrere Requests aufteilt. Da hilft aber kein File-Lock sondern du muss anhand des Datensatzinhaltes feststellen, ob du schreiben möchtest oder nicht, weil sich der Timestamp oder die RowVersion zwischenzeitlich geändert hat. Du machst dann File-Locking zusätzlich zum Concurrency Locking aus Datensicht. Mit der Datenbank hast du zumindest bei Optimistic Locking nur ein Update WHERE RowVersion=alter_wert. Und während in Villarriba … > Da wäre jetzt wieder ein reales Beispiel hilfreich, weil ich nicht erkenne, wie sich das für den blockierten User letztendlich anders auswirken soll. > Und dann haben wir noch nicht mal über Transkationen gesprochen, um komplexe Szenarien mit Beteiligung von mehrern Tabellen so anzusichern, dass bei einem eventuellen Abbruch keine Inkonsistenzen zurückbleiben. > Auch wenn voneinander abhängige Updates auf verschiedene Tabellen erfolgen, wie zb. Reservierungen/Überweisungen/etc…, sind bei Transaktionen alle Anweisungen als eine abzuhandeln, also blockiere alle oder führe alle aus. Da bei einer Flatdb der Schreibprozess ja auch geschützt ist, passiert das gleiche, oder? *edit Ah, stop, wenn es mehrere Textdateien als DB sieht das natürlich anders aus. Ok, aber bei einer einzigen? Gruss Henry

Hallo dedlfix, > Nehmen wir Inserts. Du brauchst bei der Datenbank kein Locking, um das anfangs dargestellte 4-Punkte-Szenario abzusichern. Du musst keine Sorge haben, dass jemand an die Stelle schreibt, an die du auch gerade schreiben wolltest oder deine Änderungen an der Datei überschreibt. > Natürlich, aber wäre bei flatdb und LOCK_EX ja auch so, oder nicht? > Update ist etwas komplexer, weil der Vorgang sich auf mehrere Requests aufteilt. Da hilft aber kein File-Lock sondern du muss anhand des Datensatzinhaltes feststellen, ob du schreiben möchtest oder nicht, weil sich der Timestamp oder die RowVersion zwischenzeitlich geändert hat. Du machst dann File-Locking zusätzlich zum Concurrency Locking aus Datensicht. Mit der Datenbank hast du zumindest bei Optimistic Locking nur ein Update WHERE RowVersion=alter_wert. Und während in Villarriba … > Da wäre jetzt wieder ein reales Beispiel hilfreich, weil ich nicht erkenne, wie sich das für den blockierten User letztendlich anders auswirken soll. > Und dann haben wir noch nicht mal über Transkationen gesprochen, um komplexe Szenarien mit Beteiligung von mehrern Tabellen so anzusichern, dass bei einem eventuellen Abbruch keine Inkonsistenzen zurückbleiben. > Auch wenn voneinander abhängige Updates auf verschiedene Tabellen erfolgen, wie zb. Reservierungen/Überweisungen/etc…, sind bei Transaktionen alle Anweisungen als eine abzuhandeln, also blockiere alle oder führe alle aus. Da bei einer Flatdb der Schreibporzess ja auch geschützt ist, passiert das gleiche, oder? Gruss Henry