dedlfix: Login und Rechte - Wie aufwendig?

Beitrag lesen

Tach!

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?

Vermutlich. Aber nicht vergessen und bei den anderen auch nicht. Übrigens auch im Administrationsmodus darfst du die Datei nicht offen lassen, ohne dass deine Anwendung stehenbleibt.

Update ist etwas komplexer, …

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.

Ich kann dir zum Locking nicht mit Erfahrung dienen, weil ich mir das nicht angetan habe. Ich konzentriere mich lieber auf das was ich aus anwendungtechnischer Sicht tun muss. Und was für den restlichen reibungslosen Betrieb notwendig ist, kann ruhig das DBMS erledigen. Deshalb möchte ich mir auch grad keine Gedanken machen, wie ich das komplexe Szenario mit Flatfiles erledigen würde.

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?

Wenn du mit mehreren Dateien arbeiten musst und sie sperren musst, kannst du in die Dead-Lock-Problematik geraten, wenn du die zweite Datei haben möchtest, die aber gerade gesperrt ist, weil der andere Prozess für seine Transaktion auf die Sperre für die erste wartet. Mit detaillierten Erfahrungen kann ich auch hier nicht dienen, weil ich nie die Notwendigkeit für Transaktionen hatte. Ich kann mir aber nicht vorstellen, dass das Abwickeln einer solchen mit Textdateien einfacher als ein COMMIT oder REVERT sein soll.

*edit Ah, stop, wenn es mehrere Textdateien als DB sind, sieht das natürlich anders aus. Ok, aber bei einer einzigen?

Für eine einzige wären nur die beiden ersten Szenarian zu beachten. Deine Transaktion findet dann zwischen dem Lock und dem Release statt.

dedlfix.