Hallo,

ich habe gerade mit meinem Shout einen Doppelshout zur gleichen Zeit hingelegt. Ich dachte, dass das die Richtlinien verbieten.

Viele Grüße
Regan

Regan hat folgendes geschrieben :

Ich dachte, dass das die Richtlinien verbieten.

Deshalb wirst du jetzt 24 Stunden für die Shoutbox gesperrt.

Im Ernst: Da hast du wohl so exakt gleichzeitig zweimal die Anfrage geschickt, dass der Server bei der ersten schon nach der Prüfung war, aber noch nicht eingetragen hatte, als die zweite kam. Und dann kam die auch noch an der Prüfung vorbei und beide wurden eingetragen.

Für eine Einführung der lock { }-Struktur in PHP

Die nutzt dir da auch nichts, aber eine DB mit Transaktionen

Es soll ja sowas geben, das heißt InnoDB - ach halt, das will Oracle ja einstampfen (bzw so teuer machen, dass es keiner mehr nehmen kann).

Martok hat folgendes geschrieben :

Die nutzt dir da auch nichts, aber eine DB mit Transaktionen Es soll ja sowas geben, das heißt InnoDB - ach halt, das will Oracle ja einstampfen (bzw so teuer machen, dass es keiner mehr nehmen kann).

"Eine DB mit Transaktion" löst das Problem noch nicht. Erstens müsstest du den Isolationlevel relativ hoch setzen (Repeatable Read bzw. Serializable), und zweitens läufst du dann genau in den Fall, wo du bei einer der Session eine Exception kriegst und du das ganze wiederholen musst. Denn beide wollen zunächst einen Shared-Lock auf ein Feld und wollen den Lock später auf ein Exclusive-Lock upgraden. Doch, wenn beide einen Shared-Lock bereits haben, kann weder der einen noch der andere ein Upgrade auf ein Exclusive-Lock kriegen, dafür muss der eine seinen Shared-Lock aufgeben. Eine Möglichkeit wäre Locken/Mutex und da sind wir ja auch schon beim letzten Post

Übrigens: Es gibt ja auch noch andere Datenbanken. Z.B. PostgreSQL. Die ist technisch ausgereift, hält sich an Standards und läuft gleichzeitig unter einer lockereren Lizenz. Ich persönlich würde zu mindest nie auf die Idee kommen, für irgend was MySQL einzusetzen.

delfiphan hat folgendes geschrieben :

"Eine DB mit Transaktion" löst das Problem noch nicht. Erstens müsstest du den Isolationlevel relativ hoch setzen (Repeatable Read bzw. Serializable), und zweitens läufst du dann genau in den Fall, wo du bei einer der Session eine Exception kriegst und du das ganze wiederholen musst.

Nicht unbedingt... Read Committed führt zumindest auf Oracle dazu, dass der 2. Commit dann fehlschlägt, und bis dahin nichts weiter passiert.

delfiphan hat folgendes geschrieben :

Übrigens: Es gibt ja auch noch andere Datenbanken. Z.B. PostgreSQL. Die ist technisch ausgereift, hält sich an Standards und läuft gleichzeitig unter einer lockereren Lizenz. Ich persönlich würde zu mindest nie auf die Idee kommen, für irgend was MySQL einzusetzen.

Isotopp schrieb da neulich was zu geschrieben, was ich auch so sehe. Postgres spielt eher in der Oracle-Liga, das will man allein wegen dem ganzen Overhead nicht mit PHP einsetzen. In einer Tomcat-Umgebung, wo man nicht für jeden Request alles neu erstellen muss, ginge das schon eher...

Der 2. COMMIT schlägt nicht fehl, sondern der 2. COMMIT überdeckt den ersten. D.h. es kommt zu einem Lost Update. Das ist nicht nur bei Oracle so, sondern denk ich mal bei allen DB's mit Read Committed Isolation. Aber das ist hier jetzt OT

PostgreSQL ist natürlich schon schwerer als MySQL, das ist sicher so. Aber, wenn man eine "richtige" Datenbank braucht, dann würde ich von MySQL stark wegtendieren (PS: Bevor jetzt eine Diskussion ausbricht: Ich habe mit MySQL lange nicht mehr gearbeitet. Ich bin mir sicher, dass die Leute dort in zwischen auch ein bisschen weiter sind als vor paar Jahren)

Dann kick den zweiten Commit halt mit ner Violation der Table Constraints. Dann sollten nur die Indizes richtig gesetzt sein, weil Du sonst mit deinem Table Constraint die Performance versenkst ... Aber okay, wir schweifen ab.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.