Diskussion:Transaktion (Informatik)

Erklärung besteht aus unklaren Begriffen

Quote: "Transaktionen müssen also folgenden vier Kriterien entsprechen: Atomarität, Konsistenz, Isolation und Dauerhaftigkeit (englisch ACID). Aufgrund der letzten Bedingung lassen sich ACID-Transaktionen nicht schachteln. Transaktionen sind isoliert, wenn sie serialisierbar sind."

Weiß ich nicht, was Atomarität und Isolation im Zusammenhang einer Transaktion sind, und gibt es auch keinen erklärenden Artikel dazu, dann bin ich als unbedarfter Leser aufgeschmissen. Wer kann Atomatität und die anderen in diesem Zusammenhang erläutern? Gruß --Bertram 09:06, 14. Jan 2005 (CET)

Atomar heisst nicht weiter zerlegbar. Dies gilt auch bei Transaktionen: Sie koennen nicht teilweise ausgefuehrt werden; nur ganz oder gar nicht. Isolation heisst, dass die Zwischenergebnisse nicht verfuegbar sind(sie koennen weder ausgelesen noch ueberschrieben werden). Eigentlich wollte ich es einfuegen, aber der Satz: "Transaktionen sind isoliert, wenn sie serialisierbar sind" machte mich stutzig. Meines Wissens sind alle Transaktionen serialiserbar. Nun, ich warte auf weitere Meinungen. --- alex

Ich habe den Artikel komplett überarbeitet. Dabei sind keine (richtigen) Informationen verloren gegangen, sie wurden nur anders ausgedrückt und umgeordnet. Transaktion und serialisierbar sind zwei Begriffe, die nicht zusammenhängen. Nur Historien können serialisierbar sein oder nicht. Serialisierbar bedeutet eben gerade „die Transaktionen könnten auch nacheinander ausgeführt werden“. --Thetawave 15:01, 28. Jul 2005 (CEST)

Das A in ACID, also die Atomarität bezieht sich aber imho auf die Datenhaltung selbst. Also z.B., dass eine Adresse nicht in einer Zelle, sondern aufgeteilt in Straße, Hausnummer, PLZ etc. abgelegt wird. Transaktionen sollen natürlich die ACID-Eigenschaften beibehalten, aber diese Umdeutung des A in ACID scheint mir inkorrekt zu sein, oder? 84.129.167.230 17:12, 10. Aug 2005 (CEST)

Ja und nein, 84.129.167.230. Die ACID-Eigenschaften beziehen sich ausschließlich(!) auf Transaktionen:

„Atomicity (Atomarität) Dise Eigenschaft verlangt, dass eine Transaktion als kleinste, nicht mehr weiter zerlegbare Einheit behandelt wird, d. h. entweder werden alle Änderungen der Transaktion in der Datenbasis festgeschrieben oder gar keine. Man kann sich dies auch als „alles-oder-nichts“ Prinzip merken.“ Zitat aus A.Kemper, A.Eickler: Datenbanksysteme, S. 269. Nicht weiterverwenden, unterliegt nicht der GNU-FDL!

Der Einzelbegriff „atomar“ wird aber auch in vielen anderen Zusammenhängen verwendet (z. B. in der Physik, aus der er entlehnt worden ist). So wird atomar auch verwendet, um auszudrücken dass ein Attribut einer Relation aus einem atomaren Datentyp wie integer, string, date oder time besteht und somit unteilbar ist. Diese Verwendung von atomar begründet die 1. Normalenform einer relationalen Datenbank - das hat aber nichts mit ACID zu tun. Auch die anderen Eigenschaften beziehen sich auf Transaktionen:

• consistency: Die Transaktion muss einen konsistenten Datenzustand hinterlassen.
• isolation: Die Transaktion muss isoliert von anderen Transaktionen abgewickelt werden.
• durability: Die Änderungen einer Transaktion müssen dauerhaft gespeichert werden.

Was verwirrend wirkt, ist, dass Dinge wie Konsistenz auf den ersten Blick die Datenhaltung betreffen und nicht die Änderungen von Transaktionen. Das kommt daher, dass die Datenbanktheorie auf den formalen Grundlagen von Transaktionssystemen aufbaut - und die klammern alle Fragen physischer Datenhaltung aus. Langer Rede kurzer Sinn: ACID <-> Transaktionen. --Thetawave 23:56, 10. Aug 2005 (CEST)

Widersprüchliche Aussage

Quote: "Das Rückgängigmachen der Effekte einer Transaktion wird als Rollback (Zurücksetzen) bezeichnet. Es kann dabei vorkommen, dass das Zurücksetzen einer Transaktion das Zurücksetzen einer jeweils anderen Transaktion notwendig macht[...]"

Widerspricht dies nicht der Isolationseigenschaft?

Nein. Das widerspricht nicht der Isolation: Die Transaktion T1 macht eine Änderung am Objekt a. Danach liest die Transaktion T2 das veränderte Objekt a. Wenn T1 danach noch zurückgesetzt wird, muss auch T2 zurückgesetzt werden, weil T2 sonst einen nicht freigegebenen Wert von a gesehen hätte (Das würde der Isolation widersprechen). Wird T1 dagegen erfolgreich abgeschlossen, kann T2 auch weiterlaufen: Das entspricht dann der Hintereinanderausführung von T1 -> T2, und ist somit mit der Isolationsforderung vereinbar. Um solche kaskadierenden Rücksetzungen zu vermeiden, kann man Sperrverfahren verwenden, die die geänderten Objekte bis zum Transaktionsende sperren, damit keine andere Transaktion diese "schmutzigen Daten" (dirty data) vor der Freigabe sehen kann. Gruss, R.K.A.L. 10:57, 17. Nov. 2006 (CET)

Kaskadierte Rollbacks

Ein Rollback, der zu einem zwangsweisen Rollback anderer Transaktionen führt, ist eine Isolationverletzung. Sollte nämlich im genannten Gegenbeispiel oben zuerst die Transaktion T2 committen, welche von T1 abhängig ist, dann kann beim Rollback von T1 die bereits committete T2 nicht mehr rückgängig gemacht werden. Damit wäre das 'Durability'-Prinzip verletzt, welches jeder committeten Transaktion die Dauerhaftigkeit ihrer Daten garantiert. Das Argumentieren mit Sperrmechanismen ist unzulässig, die ACID-Regel ist ein konzeptionelles Konstrukt. Sperrmechanismen sind einer von mehreren Varianten zur Realisierung des Isolations-Prinzips.

Literaturquellen

Hallo,

kann mir bitte jemand Quellen zu den Inhalten dieses Artikels aufzeigen. Insbesondere die Aussagen eine Transaktion sei eine geordnete Menge von nacheinander auszuführenden Operationen und diese Operationen können auch nebenläufig ausgeführt werden, kann ich in der von mir bemühten Literatur nicht bestätigt finden.

Da ich in einer wissenschaftlichen Arbeit die Wikipedia nicht zitieren darf, wäre es sehr hilfreich, wenn mich jemand auf Literaturquellen, die eben diese Aussagen bestätigen, hinweisen könnte.

Vielen Dank!

Freundliche Grüße,

--Mimarox 19:07, 31. Mär. 2008 (CEST)

"Widersprüchliche Aussage", Anmerkung

... Das widerspricht nicht der Isolation: Die Transaktion T1 macht eine Änderung am Objekt a. Danach liest die Transaktion T2 das veränderte Objekt a. ...

Diese Situation ist bereits selbst eine Verletzung der Isolationsbedingung. Eine korrekte ablaufende Transaktion darf nicht unbestätigte Änderungen einer anderen Transaktion lesen. Ich finde es schade, dass Wikipedia-Einträge auf so grundlegenden und theoretisch seit längerem fundiert abgehandelten Themen zu einem Feld-Wald-Wiesen-Diskussionsforum verkommen.

Formulierung

"Um sich die wichtigsten Begriffe dieses Artikels anschaulich vorstellen zu können, soll folgendes Beispiel dienen:..." Schräge Formulierung! Vorschlag: Um sich die wichtigsten Begriffe dieses Artikels anschaulich vorstellen zu können, soll folgendes Beispiel betrachtet werden:

Atomarität vs. Atomizität

Also das Wort Atomarität habe ich hier zum ersten mal gelesen, ansonsten ist mir eher das Wort Atomizität (insbesondere bezüglich der ACID-Eigenschaften) geläufig. Taucht ersteres tatsächlich in der Literatur so auf? Atomarität hört sich irgendwie komisch an! --88.78.30.229 17:02, 2. Apr. 2010 (CEST)

Ich hab im Studium damals auch Atomarität gelernt. Insbesondere sagt man auch oft, eine Operation sei atomar, daher würde das auch passen. Atomizität lehnt sich dafür mehr an der englischen Form an, Atomicity. Leo meint übrigens, ersteres wäre aus dem Bereich der Computer, zweiteres eher aus der Physik. --Snuffels 19:14, 2. Apr. 2010 (CEST)

Einheit vs. Logische Einheit

Was ist der Unterschied zwischen Einheit und "logische Einheit"? (nicht signierter Beitrag von 87.78.207.253 (Diskussion) 02:19, 21. Jun. 2010 (CEST))

Eine logische Einheit ist eine solche, die keine wirkliche ist, aber als eine solche betrachtet wird :-) Ok, mal konkret bezogen auf Transaktionen und die Operationen dort, siehe Einleitung des Lemmas: Die Operationen, die zusammen eine Transaktion bilden, werden als Einheit betrachtet (deswegen das "logische"), aber irgendwo sind es halt doch nur Einzeloperationen, bilden also keine "echte" Einheit. Siehe das Beispiel im nächsten Absatz. Da haben wir 3 Operationen, z.B. "lies das Feld Vorbestellung der Karte" sowie zwei weitere. Alle 3 zusammen bilden in diesem Beispiel eine logische Einheit, eine Transaktion. Diese Transaktion ist erstmal unteilbar (siehe auch das A in ACID ein Abschnitt tiefer), deswegen wird sie als logische Einheit betrachtet. Halbwegs klar geworden? -- Snuffels 10:57, 21. Jun. 2010 (CEST)

Danke für die Erklärung. Könnte man das Wort "logische" in der Einleitung nicht streichen? Denn dann steht dort, dass die Folge von Operationen als Einheit betrachtet wird, was äquivalent zu Ihrer Erklärung ist. --87.78.227.137 02:42, 23. Jun. 2010 (CEST)

Hm, man könnte möglicherweise, aber zumindest meines wissens nach wäre die Version mit "logischer" die korrektere, deshalb würd ichs eher lassen wollen. Leider habe ich so auf die schnelle leider auch keinen WP-Link auf irgendwas gefunden, was man hier mit der "logischen Einheit" verknüpfen könnte, damit andere mit ähnlichen Problemen vielleicht grad dort nachlesen könnten. Ich kann noch etwas weitersuchen, aber befürchte, auch dann nichts anderes zu finden. Würde das "logischer" aber trotzdem gern lassen. Frage ins Plenum: Weitere Meinungen oder Vorschläge? --Snuffels 14:59, 23. Jun. 2010 (CEST)

Ein paar Quellen: C.J. Date: Introduction to Database Systems. 7th Ed. .Addison Wesley. 2000: "A transaction is a logical unit of work, typically involving several database operations".

Gumm, Sommer: Einführung in die Informatik. Oldenburg: "Das DBVS bietet zur Unterstützung des Mehrbenutzerbetriebs als eine neue Kontrollstruktur die Transaktion, die mehrere Elemantaroperationen zu einer logischen Einheit bündelt".

Andere Autoren sagen "Einheit der Integritätskontrolle" oder "ACID-Einheit".

schöne Grüße JohnTB 16:03, 23. Jun. 2010 (CEST)

Sinn von Transaktionen?

Sollte man nicht noch etwas über den Sinn von Tx schreiben? Also z.B. "Eine Anwendung bestizt viele Prädikate (z.B. dass die Summe aller Konten gleich 0 ist). Wenn nun Interaktionen, welche diese Prädikate nicht verletzen (also korrekt sind) als Transaktionen ausgeführt werden, dann ist dadurch die Einhaltung aller Prädikate garantiert". Quelle hierfür ist z.B. "Distributed Systems: Principles and Paradigms. Andrew S. Tanenbaum Maarten van Steen". -- 212.227.35.68 09:06, 16. Dez. 2010 (CET)

Transaktionen Datenbanken

Der hier beschriebene Vorgang von Datenbanktransaktionen ist leider falsch. Richtiger wäre: Transaktionen sind eine Folge von Datenbankaktionen, die als Einheit betrachtet werden (z.B. Geld von einem Unterkonto auf ein anderes überweisen). RzJ (nicht signierter Beitrag von 93.129.210.169 (Diskussion) 17:45, 9. Okt. 2011 (CEST))

Kontextwechsel

Ist es möglich, dass Transaktionen z.B. durch Thread- oder Prozesswechsel unterbrochen werden? Falls ja, werden diese Daten gespeichert und dann ab Abbruchpunkt weitergeführt, oder abgebrochen und neu angefangen? --Christoph.runge (Diskussion) 14:04, 30. Sep. 2013 (CEST)

Wirkungslose transaktionen

der abschnitt macht nach meinem logikverständis keinen sinn:

Eine Transaktion innerhalb eines Schedules wird als wirkungslos bezeichnet, wenn sie eine der folgenden Bedingungen erfüllt: es werden ausschließlich Leseoperationen ausgeführt es werden ausschließlich Schreiboperationen ausgeführt und die geschriebenen Werte werden – ohne zwischenzeitlich ausgelesen zu werden – von anderen Transaktionen wieder überschrieben. Wirkungslos bedeutet, dass die Transaktionen keinen Einfluss auf den Datenbestand der Datenbank hatte. Wirkungslose Transaktionen müssen demnach bei einem Rollback nicht zurückgesetzt werden.

angenommen ich hab eine variable A mit wert 5. Trasaktion1 setzt sie auf Wert 10. Dann wird NICHT gelesen. Transaktion2 setzt B dann auf 20. Dann wird gelesen. Dann wird eine Rollback druchgeführt. Wenn jetzt Tran2 zurückgesetz wird, aber nicht Tran1, dann ist A doch immer noch 10. Wo ist mein Fehler? Oder ist der Absatz falsch? (nicht signierter Beitrag von Rewireable (Diskussion | Beiträge) 11:40, 20. Jan. 2014 (CET))