MySQL Duplicate Entry Auto-Inc

[Sir Rufo]

@jobo

Wenn du mit mehr als einem Thread auf die gleiche Session zugreifst dann kann bei jeder DB alles passieren (meistens Grütze).

Jede Session ist an einen Thread gebunden und bei einer vernünftigen Implementierung (dieses Connection-Objekts) würde dir eine Exception um die Ohren fliegen, wenn du mit mehr als einem Thread gleichzeitig darauf zugreifst.

[TRomano]

Damit hast Du vollkommen Recht Sir Rufo (jeder Thread eine Connection), aber Jobo meinte, dass, wenn die ID vom DBMS erzeugt wird, eigentlich nichts passieren sollte.
Das DBMS bekommt über das INSERT-Statement eine Anforderung für eine neue ID (auto increment) und sollte diese auch entsprechend bereit stellen. Was clientseitig passiert ist da erst einmal egal (Threads) ... ist schon komisch, dass das DBMS das irgenwie nicht hinbekommt.

[Sir Rufo]

Es werden auch 2 IDs erzeugt, aber die letzte wurde bei beiden Datensätzen eingetragen (per

SQL-Code:

last_inserted_id

) :stupid:

Die beiden Statements müssen nur zeitlich sehr dumm zusammenfallen. Man spricht hier von einer race condition

[jobo]

Also ich habe sowas noch nie gehabt. Wenn sowas tatsächlich passiert, müsste ich über einen Kirchenaustritt nachdenken. ;)
Ich arbeite allerdings auch nicht produktiv mit mysql.
Bevor ich dem nachgehen würde (aus Neugier), würde ich lieber andere Dinge prüfen:
- Datentyp der Auto Inc Spalte, scheint hier groß genug
- Dictionary Schrott durch manuelle Einträge, scheints ja hier zu geben. Wurde zumindest testhalber durchgeführt. Also AutoInc Wert per Alter Table neu setzen ("heilen")
- Sicherstellen(!), dass die Grundannahme "nur ein Client" tatsächlich richtig ist.

[TRomano]

@Sir Rufo: Okay. Wenn man nur eine Connection für mehrere Threads (mit INSERT-Statements) benutzt kann die MySQL-Server-Variable LAST_INSERTED_ID nicht unbedint dem entsprechen, was man sich so vorstellt ... das hatte ich nicht beachtet.
Ich gehe einfach davon aus, dass MySQL die ID´s richtig erzeugt (AutoInc), sonst hätten wir schon Gegenteiliges gehört :-D

@jobo: du musst bestimmt nicht deswegen aus der Kirche austreten, hier läuft bestimmt was Anderes schief ... :?

[borncrush]

Mich wundert das auch arg.

Wir befeuern einige MySQL Server mit vielen, gar massig an Datensätzen. Teilweise Standortdaten zur Routenberechnnung in Logistikzentren. Da kommen teilweise viele Datensätze in einer Sekunde an. Wir konnten aber noch nie diesen Effekt beobachten mit MySQL+MSSQL (hier nicht gefragt) beobachten. Mehr Datenbankverwaltungssysteme kenne ich nicht produktiv.

Du schließt die Übergabe der ID (des PK / AI-Feldes) aus. Somit ist also MySQL gefragt. --> ok
Sicherlich habt ihr die my.ini konfiguriert. Könnte Dir da ein Zusammenhang einfallen? (Clustern werdet ihr ja nicht, oder?? Da fehlt mir die Erfahrung)
Andernfalls interessiert mich noch die Storage-Engine. --> InnoDB?

[jobo]

Zitat:

Zitat von TRomano (Beitrag 1325580)

@jobo: du musst bestimmt nicht deswegen aus der Kirche austreten, hier läuft bestimmt was Anderes schief ... :?

Wenn ich es mir genau überlege, ist es hier wie überall die Frage, kämpfe ich innerhalb des Systems um Verbesserungen oder such ich mir was besseres.
Bei mysql war ich zum Glück noch nie gezwungen, es produktiv zu verwenden.

[JRichmann]

Hallo...

>Hat denn jeder Thread auch seine eigene Connection?

Ja

Die DB kann ich leider nicht so einfach wechseln

[JRichmann]

>Du schließt die Übergabe der ID (des PK / AI-Feldes) aus. Somit ist also MySQL gefragt. --> ok

Ja

>Sicherlich habt ihr die my.ini konfiguriert. Könnte Dir da ein Zusammenhang einfallen? (Clustern werdet ihr ja nicht, oder?? Da fehlt mir die Erfahrung)

Default Werte

>Andernfalls interessiert mich noch die Storage-Engine. --> InnoDB?

InnoDB

[TRomano]

@Jobo: ich bin auch nicht wirklich ein großer Freund von mySQL (alleine ein Wechsel auf Version 5.7 von 5.6.xx brachte einen Haufen Ärger), aber des Kunden Wunsch sei mir Befehl !
Für die dortige einfache DB hätte ich weiterhin Firebird genommen (alleine schon weger der Lizenz-Problematik). Aber man wollte dort bei der Hansestadt die IT-Landschaft vereinheitlichen. Ich habe mich durchgekämpft und es läuft sehr stabil. Es sind aber auch keine riesigen Datenmengen, so dass ich zur Stabilität dahingehend nichts sagen kann und will.