ich würde gern wissen, ob einer von euch eine neue Version (4.3.x) hat und folgendes Verhalten bestätigen kann.
Zwei Kunden bestellen zeitgleich, der eine bekommt die richtige Bestellnummer (fortlaufend), der andere Kunde bekommt die Bestellnummer 0. Ich habe dazu bereits einen Bugeintrag verfasst, allerdings nutzen wir noch die Version 4.1.2 und ich könnte mir vorstellen, dass das aufgrund dessen abgelehnt werden könnte.
Im Anhang noch ein Screenshot vom Fehlverhalten. Wäre super, wenn den Fehler jemand bestätigen könnte oder eben sagen würde, dass das bereits behoben wurde.
Fakt ist, dass dieser Bug seit ich Oxid kenne besteht und noch nie abschliessend gelöst wurde.
Um dieses Problem abschliessend zu lösen kann ich mir nur vorstellen, dass Oxid die Art und Weise ändert wie der Shop Bestellzeilen schreibt. Momentan wird mittels MySql die maximale Bestellnummer ermittelt und dann dreckig mit einem +1 versehen…
Hier sollte man meiner Meinung nach mal endlich mit MySql Auto_Increment arbeiten oder eine echte MySql Transaktion implementieren.
2 Sachen sind mir immer wieder bei der Analyse aufgefallen.
Es passiert immer dann, wenn eine Kreditkartenzahlung abgelehnt wird. Zum Zeitpunkt der Validierung schreibt der Shop ja schon die Bestellzeile in die oxorder. Wird die Zahlung abgelehnt oder hat sich ein Fehler eingeschlichen wir d die oxorder bestellzeile gelöscht.
Sind nun im Shop 2 Leute gleichzeitig dabei eine Bestellung durchzuziehen knallt es und es tauchen die doppelten Bestellzeilen auf.
Ein wenig Abhilfe schafft in der config.inc.php:
$this->iOrderNrPrecisionCnt = 30;
Wie gesagt, kann ich nur für die 2.7 EE sprechen.
Was mir noch aufgefallen ist, dass es gerade im iPayment Modul häufiger zu diesem Fehler kam. Momentan setzen wir das Heidelpay Modul ein und da scheint dieser Fehler nur noch sehr sehr sehr sehr selten aufzutauchen.
Hier sollte man meiner Meinung nach mal endlich mit MySql Auto_Increment arbeiten oder eine echte MySql Transaktion implementieren.
Irgendwo hatte ich mal gelesen das das mindestens geplant, wenn nicht sogar schon implementiert ist. Theoretisch könnte man auch mit wenigen Zeilen PHP und einem kleinen SQL Statement ein kleines Modul schreiben was den Bug behebt.
Transaktionen werden schwierig, da ja überall noch MyISAM eingesetzt wird statt InnoDB, auch das ändert man gerade wohl, gabs auch letztens eine diskussion auf der Mailingliste zu dem Thema.
Gerade bei Shop Systemen finde ich, das Performance definitiv HINTER Datensicherheit und Integrität kommt. Das heisst nicht das man jetzt Performance völlig vernachlässigen sollte, aber es ist wichtiger das die Bestellung korrekt verarbeitet wird, als das sie schnell verarbeitet wird. Zudem kann man alles irgendwie optimieren.
bin gerade durch Zufall über das Thema gestolpert.
Es würde auch zwei einfache SQL-Statements ausreichen: Vorher LOCK TABLES oxorder WRITE und nachher UNLOCK TABLES. Das ist absolut legitim, da MyISAM sowieso nur table base locking bei Inserts verwendet und das Bottleneck somit sowieso eher bei der Storage Engine liegt. Noch ein kleines try-finally drumrum und deadlocks durch starvation sind auch kein Thema.
Also, an soeiner Stelle nicht Threadsicher zu programmieren ist echt stümperhaft. Meine zwei Cents.
