Drupal user
Fórum
Drupal version

Ahoj potřebovala bych se poradit v posledních 2 týdnech se nám shopu zobrazuje toto hlášení:

1) PDOException: SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; try restarting transaction: UPDATE {commerce_order} SET order_number=:db_update_placeholder_0...

2) DatabaseTransactionOutOfOrderException: ve funkci DatabaseConnection->rollback() (řádek: 1141...includes/database/database.inc

a místo stránky potvrzující objednáku, hlásí error 500

Problém je že objednávka se pak nepřesune do stavu Complete a pořád je jako, že ji udělal anonymní uživatel a platba je přitom označená jako zaplacená, zákazníku je odeslán email...s platební bránou taky není problém tam se vše uděje jak má..jen na drupalu potvrzující závěrečná stránka objednávky je K.O. :-)

Vždy se jedná o platbu přes platební bránu Comgate firma platiti.cz, komunikovali jsme s jejich podporou a závěr jejich modul funguje dobře, oni jen předávaní do commerce_checkout_complete($order), ale drupal zřejmě má nějaký problém se zamikáním innodb transakcí...

Objednávky přes dobírku či bankovní převod fungují normálně...

Googlovali jsme a našli jsme na drupla.org několik témat a asi nejvíce se to blíží tomuto:

https://www.drupal.org/project/commerce/issues/2240427

a poslednímu komentáři, který v podstatě popisuje náš problém:

It seems like progress made on D8/D9 is unlikely to flow back downstream at this point, looking at the types of solutions being discussed. I still have this problem show up from time to time, despite implementing some of the patches suggested above. Most problematically, it occasionally happens in the transition from checkout review to completion which means payment transactions happen, but the order doesn't move to "completed" and the user is presented with the review page again. This has led to customers paying for their orders multiple times.

Is it likely that any sql / hosting tuning could have a mitigating impact here? If transactions take longer to complete, are they locked for longer and increase the risk of overlap? Has anyone attempted the "SHARE MODE" approach indicated above as a core hack, and if so were there any downstream effects to be aware of?

Zkoušeli jsme udělat i změnu v jádru (vím, že se to nemá):

if ($this->forUpdate) { $query .= ' FOR UPDATE'; }

with

if ($this->forUpdate) { $query .= ' LOCK IN SHARE MODE'; }

Ale nepomohlo to.

Našla jsem ještě tohle téma:

https://drupal.stackexchange.com/questions/108588/how-to-get-rid-of-deadlocks-and-lock-time-out-type-issues

kde na konci doporučují modul: 

Asynchronous Prefetch Database Query Cache ale nutné nainstalovat nějaký modul do PHP mysqlnd driver.

Už se někdo setkal s podobným problémem?

Moc děkuji za pomoc!

K.

 

Ahoj, díky za link to jsme zatím nezkoušeli, nyní se snažíme zjistit příčinu... zdá se a to je můj názor, že modul Comgate by potřeboval asi nějakou optimalizaci..vycházím z toho, že když zákazníci platí přes Paypal (modul Commerce PayPal) žádná chyba se nevyskytne, ale u Comagate modulu ano a to téměř vždy (myslím, že princip fungování obou modulů by měl být stejný, přesměrování na platební stránku a zpět na eshop).

Jakmile vyzkouším dám vědět jaký bude výsledek

K.

Už jsme přišli na to kde je asi problém..používali jsme vlastní template pro závěrečnou stránku potvrzující objednávku (stav: Complete) a to jsme dělali podle návodu viz. http://theoleschool.com/blog/templating-commerce-order-completion-pane (chtěli jsme si nastylovat závěrečnou stránku objednávky podle sebe)

Když jsme tuto úpravu odstranili opět vše funguje jak má...nicméně si myslím, že když s tím nemá problém modul "Commerce paypal" tak by neměl mít ani modu Comgate, asi by se chtělo podívat na to co dělá modul Comgate jinak...

K.

Přidat komentář

Ktorá rieka preteká Bratislavou?