Неправильно відображає статус у процесі (у списку інший) і не списало товар, хоча "типу" перейшло на етап

Загалом проблема в принципі очевидна. Це відбувається коли mysql не встигає обробити швидко запити і блокує таблиці, в ці моменти він дає помилку DEADLOCK або подібне до has gone away. І частина даних (на кшталт історія переходу статусу) можуть просто не вставитися в БД. Вирішується двома шляхами 1) підвищення потужності сервера 2) включення безпечного режиму MYSQL, який видасть тобі на екран в особу помилку, якщо якась із потрібних йому таблиць заблокована на даний момент я тобі ввімкнув пункт 2

[quote] Устименко Ігор OneBox CTO написав: Загалом проблема в принципі очевидна. Це відбувається коли mysql не встигає обробити швидко запити і блокує таблиці, в ці моменти він дає помилку DEADLOCK або подібне до has gone away. І частина даних (на кшталт історія переходу статусу) можуть просто не вставитися в БД. Вирішується 2ма шляхами 1) підвищення потужності сервера 2) включення безпечного режиму MYSQL який видасть тобі на екран в особу помилку якщо якась із потрібних йому таблиць заблокована на даний момент я тобі ввімкнув пункт 2 [/quote] 1. Що потрібно підвищувати на сервері (оперативку, процесор) ? 2. Виходити у мене якісь складні бізнес-процеси (перевести підзавдання в потрібний статуси і по підзавданням відправити статус у розетку) що сервер не може їх відпрацювати до кінця? 3. Чому не вистачило потужності списати товар, але вистачило перевести на фінішний статус, при тому що це останнє, що має зробити система? 4. Чому виникла проблема щодо процесу, у якого підпроцесів було 3 штуки, але раніше не виникала по процесу, у якого було 14 підпроцесів?

1. Я не займаюся безкоштовною аналітикою твого сервера, щоб відповідати на це питання 2. Ні не думаю 3. Таблиця могла бути заблокована іншим процесом (у тлі наприклад кроном) 4. Немає різниці скільки підпроцесів

[quote] Устименко Ігор OneBox CTO написав: 3. Таблиця могла бути заблокована іншим процесом (у тлі наприклад кроном) [/quote] Якщо це так, то це дуже схоже на баг, як на мене якщо є з системою процедури блокуючі запис або повністю таблиці, то інші процедури повинні перед апдетом спочатку уточнити чи не заблокований запис або таблиця і вже після цього проводити свою роботу (при цьому також блокувати запис або таблицю) А тут виходити так що йде шматок коду, в ньому потрібно щось апдейтити, процедура отримала відмову від БД, і потім, ну і добре піду далі, переведу в статус виконано, мені пофіг що база дала відмову, моє завдання перейти в статус виконано Наскільки я пам'ятаю ви не використовували особливо ніде принцип блокування, ви писали як код "хто останній того і тапки". Або я не правильно міркую і не правильно тебе зрозумів (просто в мене зараз баг висити виходить статус історії один, в реальності інший і хто це виправлятиме мені незрозуміло)?

[quote] Купріян Владислав Валерійович Baza.cn.ua / Integrator (FOP Kupriyan) написав: Устименко Ігор OneBox CTO написав:3. Таблиця могла бути заблокована іншим процесом (у фоні наприклад кроном) Якщо це так, то це дуже схоже на баг, як на мене якщо є з системою процедури блокуючі запис або повністю таблиці то інші процедури повинні перед апдетом спочатку уточнити чи не заблокований запис або таблиця і вже після цього проводити свою роботу (при цьому також блокувати запис або таблицю) А тут виходити так що йде шматок коду, в ньому потрібно щось апдейтить, процедура отримала відмову від БД, і потім, ну і добре піду далі, переведу в статус виконано, мені пофіг що база дала відмову, моє завдання перейти в статус виконаноНаскільки я пам'ятаю ви не використовували особливо ніде принцип блокування, ви писали на кшталт код "хто останній того і тапки". Або я не правильно міркую і не правильно тебе зрозумів (просто у мене зараз баг висити виходить статус історії один, в реальності інший і хто це виправлятиме мені незрозуміло)? [/quote] Твоя теорія не вірна. Влад я не готовий сидіти і навчати тебе, що таке транзакції MYSQL + LOCK таблиць.

[quote] Устименко Ігор OneBox CTO написав: Купріян Владислав ВалерійовичBaza.cn.ua / Integrator (FOP Kupriyan) написав:Устименко Ігор OneBox CTO написав:3. Таблиця могла бути заблокована іншим процесом (у фоні наприклад кроном) Якщо це так, то це дуже схоже на баг, як на мене якщо є з системою процедури блокуючі запис або повністю таблиці то інші процедури повинні перед апдетом спочатку уточнити чи не заблокований запис або таблиця і вже після цього проводити свою роботу (при цьому також блокувати запис або таблицю) А тут виходити так що йде шматок коду, в ньому потрібно щось апдейтить, процедура отримала відмову від БД, і потім, ну і добре піду далі, переведу в статус виконано, мені пофіг що база дала відмову, моє завдання перейти в статус виконаноНаскільки я пам'ятаю ви не використовували особливо ніде принцип блокування, ви писали на кшталт код "хто останній того і тапки". Або я не правильно міркую і не правильно тебе зрозумів (просто у мене зараз баг висити виходить статус історії один, насправді інший і хто це виправлятиме мені незрозуміло) ?Твоя теорія не вірна. Влад я не готовий сидіти і навчати тебе, що таке транзакції MYSQL + LOCK таблиць. [/quote] Ігорю, я також не готовий вивчати, мені це на даний момент не потрібно, мені потрібно, щоб система працювала стабільно, поки виникають речі які лякають і не піддаються ніякій адекватній логіці (база виходить живе своїм життям, менеджер який тисне кнопку в іншій виходить реальності ). Поки мені незрозуміло в чому проблема спочатку ти говорив, що сервер, тепер блокування таблиці (як на мене це не пов'язані речі, глобально) Ти можеш мені конкретно сказати що у тебе проблема в цьому завданні з блокуванням таблиці, що б вирішити цю проблему потрібно .... або що у тебе поганий сервер, мало оперативи (далі я тестуватиму сервер і спробую отримати ще раз цю помилку і потім буду писати на хостера, щоб тестово мені збільшили параметри яких не вистачає, як минулого разу, коли ти стверджував, що потрібно додавати оперативність) ?

Зв'яжі те що я написав і даси відповідь на своє запитання Будь-яка транзакція в БД блокує таблицю, і період блокування залежить від потужності сервера, чим він потужніший тим швидше виконає операцію і розблокує таблицю і шанс потрапити на LOCK буде меншим. Так зрозуміліше?

[quote] Устименко Ігор OneBox CTO написав: Будь-яка транзакція в БД блокує таблицю, і період блокування залежить від потужності сервера, чим він потужніший тим швидше виконає операцію і розблокує таблицю і шанс потрапити на LOCK буде менше. Так зрозуміліше? [/quote] так, цілком Чому тоді дія не перевірила заблокований запис чи ні?

[quote] Купріян Владислав Валерійович Baza.cn.ua / Integrator (FOP Kupriyan) написав: Устименко Ігор OneBox CTO написав: Зв'яжи те, що я написав і відповиш на своє запитання Будь-яка транзакція в БД блокує таблицю, і період блокування залежить від потужності сервера, чим він потужніший тим швидше виконає операцію і розблокує таблицю і шанс потрапити на LOCK буде менше . Так зрозуміліше? Так, цілком Чому тоді дія не перевірила заблокований запис чи ні? [/quote] Якщо ти будеш стукати в таблицю перед кожним запитом і перевіряти LOCK вона чи ні, то кількість запитів зросте в 1000 разів.

[quote] Устименко Ігор OneBox CTO написав: Купріян Владислав Валерійович чим він потужніший тим швидше виконає операцію і розблокує таблицю і шанс потрапити на LOCK буде меншим. Так зрозуміліше? Так, цілком Чому тоді дія не перевірила заблокований запис чи ні? Якщо ти стукатимешся в таблицю перед кожним запитом і перевіряти LOCK вона чи ні, то кількість запитів зросте в 1000 разів. [/quote] Я чудово розумію що перевірка блокування це шматок коду Я брав участь у розробці ПЗ де цьому приділяли багато уваги і тому мене здивувало чому в OneBox це не робить, я також розумів що це зменшує швидкість обробки і не є критичним, при тому що є логування дій (оскільки це не зовсім облікова системі, в облікових це критичніше) Загалом я правильно розумію що те, що товар не списало, але перевело на статус на якому воно має списати це суто моя проблема (або налаштування бізнес процесу або сервера)?

[quote] Купріян Владислав Валерійович Baza.cn.ua / Integrator (FOP Kupriyan) написав: Устименко Ігор OneBox CTO написав: Купріян Владислав Валерійович і період блокування залежить від потужності сервера, чим він потужніший тим швидше виконає операцію і розблокує таблицю і шанс потрапити на LOCK буде меншим. Так зрозуміліше? Так, цілком Чому тоді дія не перевірила заблокована запис чи ні ? у розробці ПЗ де цьому приділяли багато уваги і тому мене здивувало чому в OneBox це не робить, я також розумів що це зменшує швидкість обробки і не є критичним, при тому що є логування дій (оскільки це не зовсім облікова системі, в облікових це більш критично) Загалом я правильно розумію що те, що товар не списало, але перевело на статус на якому воно має списати це суто моя проблема (або налаштування бізнес процесу або сервера)? [/quote] Розумій як хочеш - я поратися з тобою як з дитиною не збираюся та й інші теж я ще в 1-му коментарі написав тобі що зроблено для вирішення проблеми і що буде решта це суто твоя цікавість яка займає мій час

У цій задачі https://baza.cn.ua/admin/customorder/issue/23224/edit/ Неправильно відображається статус https://prnt.sc/v1m3in Можете виправити?

ні ми не займаємося таким безкоштовно

[quote] Устименко Ігор OneBox CTO написав: ні ми не займаємося таким безкоштовно [/quote] Ну так це ж баг те що система не правильно відображає в історії чи це нормально?

[quote] Устименко Ігор OneBox CTO написав: [quote] Купріян Владислав Валерійович Baza.cn.ua / Integrator (FOP Kupriyan) написав: [quote] Устименко Ігор OneBox CTO написав: ні ми не займаємося таким безкоштовно [/quote] Ну так це ж баг те що система не правильно відображає в історії чи це нормально? [/quote] тобі вже дали відповідь чому так ти можеш вирішити це питання самостійно - зробивши повторний перехід на етап [/quote] Це "ручник" виходить щоб мені це зробити потрібно відключати дії і т.д. Плюс я не впевнений, що це в одному процесі така проблема Гаразд я зроблю але мені здається це повинні були зробити ви, як наслідок бага