sql php start transaction

[ghostgambler]

hm... *misspost*

[onemorenerd]

Dem Halbwissen kann abgeholfen werden. Es ist allerdings nicht mit einem Satz getan. Generell empfehle ich dir, ein gutes Buch zu kaufen.

Das Protokoll TCP/IP hat zwar die Eigenschaft, Daten vor der Übertragung in Pakete zu zerlegen, die in beliebiger Reihenfolge beim Zielsystem ankommen können. Es garantiert aber fehlerfreie Übetragung und der Empfänger setzt die Pakete in der richtigen Reihenfolge zusammen bevor er deren Inhalt an die Anwendungsschicht weiter reicht. Dadurch wird die Datenübertragung per TCP/IP zur Blackbox. Du mußt dich nicht darum kümmern, wie es abläuft, kannst einfach davon ausgehen, dass die Daten so ankommen, wie sie gesendet wurden. Übrigens gilt das selbe für Socket-Verbindungen.

Soweit die Theorie. Du befürchtest anscheinend, dass zwei Requests an dein PHP-Script gehen, dadurch zweimal die UPDATE-Query an die Datenbank geschickt wird. Sei beruhigt, das ist gar kein Problem. Alle DBS funktionieren insofern ähnlich (o.B.d.A. vereinfacht beschrieben): Sie können mehrere Queries gleichzeitig empfangen, wobei sie den SQL-Code jeder Query erstmal in einen separaten Puffer laden bis die Query komplett empfangen wurde. Wir nehmen an, dass das bei deinen 2 UPDATEs absolut gleichzeitig beendet ist.
Nun wird jede Query analysiert und ggf. optimiert. Wir nehmen immernoch Gleichzeitigkeit an.
Dann werden für jede Query ein Ausführungsplan erzeugt. Dafür ermittelt das DBS eine günstige Reihenfolge der Ausführung der Query, berücksichtigt dabei andere Queries, die gerade anstehen, Daten die von der Platte oder aus dem Speicher gelesen werden müssen, Sperren, die dafür gesetzt werden müssen und vieles mehr. Hier wird die Gleichzeitigkeit deiner 2 UPDATEs notgedrungen beseitigt (wg. I in ACID). Da beide Queries auf den selben Daten eine Schreibsperre benötigen, aber Schreibsperren immer exklusiv sind, muß das DBMS ein UPDATE zuerst ausführen. Dazu startet es eine Transaktion (wg. A in ACID), holt sich alle geplanten Sperren, führt die Query aus, gibt die Sperren frei und beendet die Transaktion. Erst jetzt kann das zweite UPDATE seine Sperren erhalten. Da sich die Datensätze inzwischen verändert haben, wird die WHERE-Klausel des 2. UPDATE u.U. nicht mehr erfüllt. Es kann nicht passieren, dass das 2. UPDATE die Veränderungen des ersten UPDATE nicht sieht (wg. C in ACID).

Jetzt ist also klar, dass gleichzeitige UPDATEs kein Problem sind. Das gilt ebenso für alle anderen möglichen Arten der Datenmanipulation (REPLACE, INSERT, ...).

Nun zu der Frage was passiert, wenn während eines UPDATE ein SELECT ausgeführt wird. Die Antwort ist kurz: Das kann niemals passieren. Da das UPDATE eine Schreibsperre benötigt und die niemals zusammen mit einer Lesesperre (für das SELECT) vergeben wird, muß auch hier wieder eine Query zuerst ausgeführt werden.
Wird das SELECT zuerst ausgeführt, liest es die noch unveränderten Daten. Anschließend werden diese durch das UPDATE verändert, aber es ist kein Dirty Read gewesen, denn das SELECT hat einen konsistenten Zustand gesehen.
Wird zuerst das UPDATE ausgeführt, werden die Daten eben erst verändert und das SELECT sieht den resultierenden konsistenten Zustand. Wieder kein Dirty Read.

Wie du siehst, ist ein DBS auch wie eine Blackbox. Man muß eigentlich nicht wissen wie es bestimmte Dinge regelt sondern kann sich auf zugesicherte Eigenschaften (vor allem ACID) verlassen.

Dennoch schadet Hintergrundwissen nicht. Das oben verlinkte Buch ist sein Geld wirklich wert, wenn auch nicht ganz leicht zu verstehen.

EDIT:

---

ganz vergessen: "UPDATE denied" sagt MySQL, wenn der User kein UPDATE-Recht hat. Ändere das einfach und es wird gehen.

---

[Xadine]

ja danke schön das war echt hiflreich zum verständnis.
zum buch werde ich mir das denke ich das nächste mal inner stadt kaufen. php5&mysql5 von markt und technik ist super aber datenbank technisch nicht so weit wie das was du empholen hast. da steht zu acid und innoDB nicht besonders viel(2-3) seiten.

ich denke mit tcp Ip da hast du mich missverstanden, bzw ich hab mich falsch ausgedrückt. wie dem auch sei.


Das was du zu den gleichzeitigen updates gesagt hast leuchtet ein und ist genau das was ich nicht gefunden habe, vielleicht hätte ich mir so ein buch vorher anschaffen sollen.

ich dachte auch acid würde nur von innoDB zugesichert..,

ach kurz um ich lies mich da mal ein.

vielen dank und mann sieht sich hier bestimmt noch,
schönen tag bis dahin
Xadine

ps. hab die rechte dirket nach meinem jaaaaaaaaaaaaaaaaaaaaaaaaaa
vergeben

[onemorenerd]

Noch ein Wort, bevor du 50 Euro für das Buch ausgibst: Es steht nichts über InnoDB drin. Das Buch beschäftigt sich rein theoretisch mit Datenbanksystemen im Allgemeinen. Es bezieht sich nicht auf ein bestimmtes Produkt oder Komponenten eines bestimmten Produkts!

Wenn du nur was über MySQL lernen möchtest, kauf dir lieber den Kofler (quasi das Standardwerk in Sachen MySQL) oder das von dir genannte Buch (kenne ich nicht).

Übrigens gibts in Sachen ACID nicht nur ja/nein. Es gibt z.B. vier Isolationslevel und MySQL kann volles ACID mit höchstem IL nur mit InnoDB. Brauchst du hier aber nicht, MyISAM wäre auch gut genug.

[ghostgambler]

Also ich habe mein Wissen komplett aus dem Internet und habe bisher kein Buch gefunden, was auch nur annähernd an den aktuellen Stand ran reichte...
Ich persönlich kenne das Buch nicht, würde aber nicht unbedingt dazu raten einfach ein Buch zu kaufen.

Gerade die Webprogrammierung ist im Internet sehr reich mit Dokumentationen und Erkenntnissen gespickt, die in einem Buch meist veraltet sind, noch bevor es in Druck geht...

[Xadine]

also meistens mache ich es ja auch so dass ich in die uni bibliothek gehe und mir dann erstmal 3-4 bücher hole. dann eins speziell nochmal über sql und dann soetwas theoretisches über datenbanksysteme. wollte hier auch kein profi darin werden. hatte nur das problem eben das ich nicht wusste wie ich das am besten handle mit dem update und dazwischen ein select.
mehr als select update und delete bracuh ich für meine sache nicht, und paar andere sachen vielleicht.