On Wed, 04 Sep 2002 23:01:06 +0200, Konrad Rosenbaum wrote:
Jedenfalls geht es darum, die Daten konsistent zu halten, und wenn nach einem Stromausfall aus einer 1 eine 0 wird, verstößt das auch gegen das ACID-Prinzip.
Um genau zu sein gegen C (Consistency).
Nicht zwingend. Wenn in der Mitarbeitertabelle, Spalte Name aus "Rosenbaum" ein "Rosentraum" wird, hat das auf C höchstwahrscheinlich keine Einfluß. Dieser Fall fällt unter D, der in etwa besagt, daß alle Daten nach Abschluß der Transe :) so bleiben wie sie sind, außer sie werden von einer anderen Transe erneut manipuliert.
Datenbank-basierte Dateisysteme gibt es auch noch...
Bitte kein Oracle Marketing!
DB-basierte Dateisysteme sind so ziemlich der groesste Schwachsinn,
Letzlich sind alle Dateisysteme DB-basiert. Man darf sich nur keine gar zu enge Definition von DB hernehmen.
den die erfunden haben (neben dem Marketinggag mit dem "i" in der Version): fuer ein FS gibt es keine Moeglichkeit Anfang und Ende einer Transaktion anzuzeigen, ausser Locks und die kann man viel besser mit einem normalen FS abbilden.
Genauso wie locks könnte man einen Transaktionsmechanismus für Filesysteme standardisieren. Bei locks muß sich sich der Programmierer um alles selbst einen Kopf machen. Dead locks und eventuell trotz lock mögliche Parallelität wären 2 Themen. Locks sind nur ein primitives Werkzeug, um transaktions- ähnliche Absicherungen zwischen Programmen/Threads zu bauen.
Programmierung mit locks macht viel Arbeit, bietet Fehlermöglichkeiten and kostet Zeit. Man _kann_ mit locks die effektiveren Programme schreiben, da man als Programmierer genau weiß, was passieren kann. Man muß dabei dummerweise für jedes Programm die locks neu optimieren. In der Praxis passiert sowas selten. Da wird eben das ganze File gelockt und basta. Mit expliziten Transaktionen kommt man zwar nicht an die Effizienz aufwändig optimierter Locks ran, bekommt aber mit minimalem Aufwand erstmal sein Programm korrekt zum Laufen. Transaktionen sind wirklich eine extrem hilfreiche Spielerei. Bleibt die Frage, wo man die Transaktions- unterstüztzungen einbaut: Am besten natürlich weit unten und darauf aufbauend in jeder Schicht. Das wurde allerdings verpennt. Datenbanken wie Oracle arbeiten deshalb direkt auf Blockgeräten und basteln sich darauf einen eigenen Transaktionsmechanismus für den Platten-IO. Wenn es Filesystem mit Transaktioen überall gäbe, hätten sie darauf aufsetzten können.
Übrigens: Bei neueren Entwicklungen (Java2EE) kannst du nicht nur FS- und DB-Zugriffe in Transaktionen stecken sondern den ganzen Programmablauf - also auch Methodenaufrufe. Du kannst solchen transaktional ablaufenden Code auch noch in Transaktionen beliebig schachteln. Wenn du das per Hand mit locks realisieren willst, brauchst du Jahre. Einem Low-Level-Hacker mag das idiotisch vorkommen. Die Praxis zeigt aber, das solche Mechanismen gern angenommen weden, weil sie eben in kurzer Zeit zu korrekten Anwendungen führen. DARAUF kommt es an. Effizienz innnerhalb der Anwendung interessiert oft keine Sau. Da wird nur soweit optimiert, daß das Programm gerade so ausreichend schnell ist. Die Anwendung vertrödelt sowieso die meiste Zeit mit Warten auf die DB.
BTW: locks vs. Transaktionen ist die gleiche Diskussion wie Assembler vs. C. Klar _kann_ man mit Assembler die besseren Programme schreiben. Trotzdem entsteht viel mehr Software in C, weil die Vorteile von C den Effizienznachteil in 9x% der Fälle überkompensieren.
Reinhard