Version 2.8.5. - Bestellungen "verschwinden"

In diesem Forum können Fragen zum OrderSprinter gestellt werden.
irrsinn.de
Beiträge: 40
Registriert: Di 2. Jan 2018, 17:07

Re: Version 2.8.5. - Bestellungen "verschwinden"

Beitrag von irrsinn.de »

Hallo Stefan,

wir haben uns jetzt mal den Aufwand gemacht und sind in den Kaninchenbau hinabgestiegen und haben folgendes vorgefunden:

Das Problem findet seinen Ursprung wenn die TSE aktiv ist und Buchungen signiert.
Also fangen wir an in der Methode addProductListToQueueCore

Um dem Problem auf die Spur zu kommen ist es wichtig, das wir verstehen das in der Methode addProductListToQueueCore die Datenbank Transaction gestartet wird:

Code: Alles auswählen

public function addProductListToQueueCore($pdo,$ordertime,$theTableid,$prods,$doPrint,$payprinttype,$userid,$quickcash, $order = null,$orderOption="") {

                if (intval($theTableid) == 0) {
                        $theTableid = null; // togo room
                }

                if (!is_null($order)) {
                      $order->setCreatorid($userid);
                }
                $printAndQueueJobs = CommonUtils::getConfigValue($pdo, "printandqueuejobs", 0);
                if ($printAndQueueJobs == 1) {
                        $doPrint = 1;
                }

                $pdo->beginTransaction();
Siehe hier $pdo->beginnTransaction. Nun finden im Code eine Reihe vorbereitender Maßnahmen statt. Ist die TSE aktiv, so wird dann innerhalb der Methode die Methode signAtTSE gecalled. Der Methode wird dann das PDO-Objekt mit der gestarteten Transaktion übergeben. Die Methode signAtTSE reicht ihrerseits dann die Daten nach erfolgreicher Signierung weiter an die Methode createOperations der Klasse Operations.

Und hier wird es dann interessant:
Wir haben hier in der Klasse das PDO-Objekt mit der laufenden Transaktion rein bekommen. Um die Daten in die Table os_operations schreiben zu können werden vorher zwei neue IDs selbst kreiert. Das das schief gehen kann findet sich auch im Code.

Code: Alles auswählen

           // In parallel transactions and with transaction isolatoon level REPEATABLE READ it may be possible that the max id is already set by another transaction.
            // Therefore run this in a try catch block just in case of a deadlock and increment the maxid in catch
            // In a very very unikely case of race condition still the bonid can be created multiple times, but the unique primary key id is evidence that there is no
            // intention in creating an invalid operation. Therefore also this comment is left in this source code!
Und beim Versuch die Daten zu schreiben wird dann eine Exception gefangen, wenn es die ID schon geben sollte.

Code: Alles auswählen

                      try {
                                if ($maxtries == 4) {
                                        $signtxt = $signtxt_ascii;
                                        error_log("Using from now on the ascii version of the signtxt to store in operations table");
                                }
                                CommonUtils::execSql($pdo, $sql, array($maxid+1,$range,$maxbonid+1,$opType,$table,$logtime,$trans, $sigcounter, $tseSignature, $pubkeyRef, $sigalgRef, $serialNoRef,$certificateRef, $signtxt, $tseerror, $terminalEntryId));
                                $ok = true;
                        } catch (Exception $ex) {
                                $maxid++;
                                $attempt++;
                                $maxtries--;
                                sleep(1);
                        }
Aber diese Exception wird niemals fliegen, da wir uns in einer Transaktion befinden und die IDs selbst erstellt haben. Die Datenbank Transaktion hat keine Kenntnis von den IDs und glaubt und. Also werden hier bei einer zeitgleichen Transaktion eine die gleiche maxid und maxbonid.

Das fällt aber erst beim finalen commit auf und die Daten werden nicht in die Datenbank geschrieben.

--------------------

Lieber Stefan,

konnten wir Dir damit helfen? Sollen wir versuchen das selbst zu lösen und Dir das dann in die Hand drücken?
Viele Grüße

Lutz
daniel
Beiträge: 126
Registriert: Fr 9. Aug 2019, 11:41
Kontaktdaten:

Re: Version 2.8.5. - Bestellungen "verschwinden"

Beitrag von daniel »

Hallo Lutz,
Hallo Stefan,

ich habe es bei mir auf einem System getestet: allerdings "nur" mit Ordersprinter 2.8.1 und ohne TSE

mit dem Vorgehen: "2 Handys, Buchung jeweils 1 Artikel auf einen Tisch (wobei sowohl der Artikel, als auch der Tisch bei jedem Handy ein anderer ist - ich habe auch unterschiedliche Benutzer verwendet) - dann habe ich annähernd zeitgleich auf Arbeitsbon (im 1. Versuch) oder auf Kasse (im 2. Versuch) geklickt.

dabei sind bei mir leider oder zum Glück KEINE Bestellungen verschwunden.

Viele Grüße Daniel
irrsinn.de
Beiträge: 40
Registriert: Di 2. Jan 2018, 17:07

Re: Version 2.8.5. - Bestellungen "verschwinden"

Beitrag von irrsinn.de »

Hallo Daniel,

Das Problem tritt NUR bei aktiver TSE-Signierung auf. Hatte ich das oben vergessen zu erwähnen? Wir hatten die TSE testweise mal abgeschaltet und konnten es nicht nachstellen.

Nachtrag: Ich hatte einen langen Beitrag geschrieben, in dem ich auf den Code eingegangen bin. Den hat Stefan noch nicht freigeschaltet. Auf den bezog ich mich mit "Hatte ich das oben vergessen zu erwähnen?" ;)
Zuletzt geändert von irrsinn.de am Do 8. Aug 2024, 12:08, insgesamt 1-mal geändert.
Viele Grüße

Lutz
pichel
Administrator
Beiträge: 1379
Registriert: So 13. Sep 2015, 19:48
Wohnort: Hamburg
Kontaktdaten:

Re: Version 2.8.5. - Bestellungen "verschwinden"

Beitrag von pichel »

Hallo Lutz, hallo in die Runde,

einen großen Dank an Lutz, der sich in den Code eingearbeitet hat und die Fehlerursache wahrscheinlich gefunden hat. Ich habe einen Patch angehängt, der das Problem hoffentlich lösen sollte. Meine Lösung sieht so aus, dass ich die Transaktion für das Hinzufügen und Entfernen von Artikeln in/aus der Db mit dem Serializable-Isolationslevel starte. Damit können keine ID-Konflikte bei dieser Operation mehr entstehen, aber die Performance leidet darunter.

Wer mag, kann das gerne auf einer 2.8.7 ausprobieren, indem er die zip-Datei in den php-Ordner entpackt. Es sind drei Dateien (commonutils.php und queuecontent.php in den php-Ordner, operations.php in den Unterordner php/utilities). Wer also mag, kann testen, ob ich damit den Bug gelöst habe und ob die Performance darunter sehr leidet.

Ich möchte darauf hinweisen, dass der gleiche Fehler möglicherweise auch beim Kassieren passieren kann, d.h. der Patch in diesem Status wahrscheinlich noch nicht für alle umsatzrelevanten Aktionen hilft.

Gruß,

Stefan
Dateianhänge
patch-transaction.zip
(35.35 KiB) 283-mal heruntergeladen
Stefan Pichel
Entwickler der Kassensoftware OrderSprinter (http://www.ordersprinter.de)
pichel
Administrator
Beiträge: 1379
Registriert: So 13. Sep 2015, 19:48
Wohnort: Hamburg
Kontaktdaten:

Re: Version 2.8.5. - Bestellungen "verschwinden"

Beitrag von pichel »

Hallo allerseits,

ich habe gerade eine Version 2.8.8 herausgebracht, in der ich das Transaktionshandling überarbeitet habe. Es sollte jetzt zuverlässiger funktionieren, aber ich befürchte, dass darunter die Performance ein wenig leiden könnte.

Jedenfalls würde ich mich sehr über Feedback freuen, wie sich die Version verhält, wenn viele gleichzeitige Zugriffe passieren, d.h. beim Einsatz bei großen Festen. Gibt es zwischendurch Hänger, Ausfälle o.ä.? Der Praxisfall lässt sich halt nicht so gut testen.

Viele Grüße,

Stefan
Stefan Pichel
Entwickler der Kassensoftware OrderSprinter (http://www.ordersprinter.de)
Antworten