Не работает транзакция

@gena8208 · Регистрация: 20.12.2019

Author24 — интернет-сервис помощи студентам

Добрый день! Случилась такая история. Есть код

PHP    
        
            
                
                
                
                
            
        
    Скопировано
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
<?php
header('Content-Type: application/json; charset=utf-8');
require_once __DIR__ . '/../config/boot.php';
if (!isset($_SESSION['username'])) {
    header('Location: login.php');
    exit;
}
try {
    $pdo = pdo();
    $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    $clientId = $_POST['id'];
    $nal = is_numeric($_POST['nalminus']) ? -abs($_POST['nalminus']) : 0;
    $kassa = is_numeric($_POST['kassaminus']) ? -abs($_POST['kassaminus']) : 0;
    $ekv = is_numeric($_POST['ekvminus']) ? -abs($_POST['ekvminus']) : 0;
    $transfer = is_numeric($_POST['transferminus']) ? -abs($_POST['transferminus']) : 0;
    $payment_accountminus = is_numeric($_POST['payment_accountminus']) ? -abs($_POST['payment_accountminus']) : 0;
    $comment = $_POST['commentminus'];
 
 
    $pdo->beginTransaction();
 
 
    $stmt = $pdo->prepare("SELECT name, site_id, dolg FROM users WHERE id = :id");
    $stmt->bindParam(':id', $clientId);
    $stmt->execute();
    $clientData = $stmt->fetch();
    $dolg = $clientData['dolg'];
 
    if (!$clientData) {
        $pdo->rollBack();
        echo json_encode(['status' => 'error', 'message' => 'Клиент не найден.']);
        return;
    }
    $office = $_SESSION['office'];
    $manager_name = $_SESSION['username'];
    if (empty($nal)) $nal = 0;
    if (empty($kassa)) $kassa = 0;
    if (empty($ekv)) $ekv = 0;
    if (empty($transfer)) $transfer = 0;
    if (empty($payment_accountminus)) $payment_accountminus = 0;
    $shipment = 0;
    // Операция 1. Сохранить данные в таблицу kassa
    $stmt1 = $pdo->prepare("INSERT INTO kassa (date, name, site_id, user_id, cash, kassa, acquiring, transfer, payment_account, shipment, comment, office, manager_name) VALUES (:date, :name, :site_id, :user_id, :cash, :kassa, :acquiring, :transfer, :payment_account, :shipment, :comment, :office, :manager_name)");
    date_default_timezone_set('Europe/Moscow');
    $todayDate = date('Y-m-d H:i:s');
    $stmt1->bindParam(':date', $todayDate);
    $stmt1->bindParam(':name', $clientData['name']);
    $stmt1->bindParam(':site_id', $clientData['site_id']);
    $stmt1->bindParam(':user_id', $clientId);
    $stmt1->bindParam(':cash', $nal);
    $stmt1->bindParam(':kassa', $kassa);
    $stmt1->bindParam(':acquiring', $ekv);
    $stmt1->bindParam(':transfer', $transfer);
    $stmt1->bindParam(':payment_account', $payment_accountminus);
    $stmt1->bindParam(':shipment', $shipment);
    $stmt1->bindParam(':comment', $comment);
    $stmt1->bindParam(':office', $office);
    $stmt1->bindParam(':manager_name', $manager_name);
    $stmt1->execute();
    $sumall = (int)$nal + (int)$kassa + (int)$ekv + (int)$transfer + (int)$payment_accountminus;
    $dolg = (int)$clientData['dolg'] + $sumall;
 // Операция 2. Обновление долга
    $stmt2 = $pdo->prepare("UPDATE users SET dolg = :dolg WHERE id = :id");
    $stmt2->bindParam(':dolg', $dolg);
    $stmt2->bindParam(':id', $clientId);
    $stmt2->execute();
    $pdo->commit();
    echo json_encode(['status' => 'success']);
} catch (PDOException $e) {
    $pdo->rollBack();
    echo json_encode(['status' => 'error', 'message' => 'Ошибка: ' . $e->getMessage()]);
}

Во время работы транзакции происходит подвисание инета и в итоге первая операция внесения в кассу происходит нормально, а вторая операция изменение баланса клиента не происходит. Для чего тогда нужна транзакция или я не верно ее использую? Перед выполнением транзакции я проверяю подключение к БД и затем выполняю ее. Как этого избежать? Как решить проблему целостности или атомарности. Если можно то простыми словами, кодом.

quwy · 22.01.2025, 19:26

БД какая? Не все базы (и не все движки в некоторых базах) поддерживают транзакции.

@gena8208 · 23.01.2025, 17:20 **[ТС]**

Сообщение от quwy

БД какая? Не все базы (и не все движки в некоторых базах) поддерживают транзакции.

Mysql InnoDB

quwy · 23.01.2025, 17:57

Сообщение от gena8208

Mysql InnoDB

Он-то транзакции поддерживает, но вы как-то не правильно представляете себе работу серверных скриптов.

Сообщение от gena8208

Во время работы транзакции происходит подвисание инета

"Подвисание интернета" на работу PHP-скрипта влияет весьма опосредственно. Не прервется скрипт мгновенно при пропадании связи с клиентом. На "осознание" проблемы сетевому стеку нужно как минимум несколько секунд (или даже десятков секунд). Причем это время должно пройти пока открыта транзакция.

В коде у вас все выглядит правильно, но проблема скорее всего в другом месте.

@gena8208 · 23.01.2025, 18:12 **[ТС]**

Сообщение от quwy

В коде у вас все выглядит правильно, но проблема скорее всего в другом месте.

Оператор вносит в кассу сумму. Инет подвис. Видимо (мое предположение)она не дождалась статус что данные внесены или статус обо ошибке. Она несколько раз жмет кнопку сохранить . Потом инет отвисает. В таблице касса появляется несколько одинаковых записей. А в таблице клиент баланс клиента не обновился

Добавлено через 3 минуты

Сообщение от quwy

"Подвисание интернета" на работу PHP-скрипта влияет весьма опосредственно.

При нажатии кнопки сохранить должно появляться сообщение что данные внесены и модальное окно закрывается. но оно не закрылось и сообщения об ошибке не появилось и что данные не сохранены не было сообщения. С этим файлом работает 10 операторов и только у одного случилось это за все время работы. сейчас я сделал логирование операций но это тоже не защитит от глюков, наверное.

PHP    
        
            
                
                
                
                
            
        
    Скопировано
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
<?php
header('Content-Type: application/json; charset=utf-8');
require_once __DIR__ . '/../config/boot.php';
if (!isset($_SESSION['username'])) {
    header('Location: login.php');
    exit;
}
try {
    $pdo = pdo();
    $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
 
    $clientId = $_POST['id'];
    $nal = $_POST['cash'];
    $kassa = $_POST['kassa'];
    $ekv = $_POST['acquiring'];
    $transfer = $_POST['transfer'];
    $payment_account = $_POST['payment_account'];
    $comment = $_POST['comment'];
 
    $pdo->beginTransaction();
 
 
    $stmt = $pdo->prepare("SELECT name, site_id, dolg FROM users WHERE id = :id");
    $stmt->bindParam(':id', $clientId);
    $stmt->execute();
    $clientData = $stmt->fetch();
    $dolg = $clientData['dolg'];
 
    if (!$clientData) {
        $pdo->rollBack();
        echo json_encode(['status' => 'error', 'message' => 'Клиент не найден.']);
        return;
    }
    $office = $_SESSION['office'];
    $manager_name = $_SESSION['username'];
    if (empty($nal)) $nal = 0;
    if (empty($kassa)) $kassa = 0;
    if (empty($ekv)) $ekv = 0;
    if (empty($transfer)) $transfer = 0;
    if (empty($payment_account)) $payment_account = 0;
    $shipment = 0;
    // сохранить данные в таблицу kassa
    $stmt1 = $pdo->prepare("INSERT INTO kassa (date, name, site_id, user_id, cash, kassa, acquiring, transfer, payment_account, shipment, comment, office, manager_name) VALUES (:date, :name, :site_id, :user_id, :cash, :kassa, :acquiring, :transfer, :payment_account, :shipment, :comment, :office, :manager_name)");
    date_default_timezone_set('Europe/Moscow');
    $todayDate = date('Y-m-d H:i:s');
    $stmt1->bindParam(':date', $todayDate);
    $stmt1->bindParam(':name', $clientData['name']);
    $stmt1->bindParam(':site_id', $clientData['site_id']);
    $stmt1->bindParam(':user_id', $clientId);
    $stmt1->bindParam(':cash', $nal);
    $stmt1->bindParam(':kassa', $kassa);
    $stmt1->bindParam(':acquiring', $ekv);
    $stmt1->bindParam(':transfer', $transfer);
    $stmt1->bindParam(':payment_account', $payment_account);
    $stmt1->bindParam(':shipment', $shipment);
    $stmt1->bindParam(':comment', $comment);
    $stmt1->bindParam(':office', $office);
    $stmt1->bindParam(':manager_name', $manager_name);
    $stmt1->execute();
    $logMessage = "";
    $logMessage = "[" . $todayDate . "] Операция: Внесение данных в таблицу kassa\n";
    $logMessage .= "clientId: " . $clientId . ", nal: " . $nal . ", kassa: " . $kassa . ", ekv: " . $ekv . ", transfer: " . $transfer . ", payment_account: " . $payment_account . ", comment: " . $comment . ", office: " . $office . ", manager_name: " . $manager_name . "\n";
    error_log($logMessage, 3, 'logs/vnesenie_v_kasse.log');
    $sumall = (int)$nal + (int)$kassa + (int)$ekv + (int)$transfer + (int)$payment_account;
    $dolg = (int)$clientData['dolg'] + $sumall;
    $stmt2 = $pdo->prepare("UPDATE users SET dolg = :dolg WHERE id = :id");
    $stmt2->bindParam(':dolg', $dolg);
    $stmt2->bindParam(':id', $clientId);
    $stmt2->execute();
    $logMessage = "";
    $logMessage = "[" . $todayDate . "] Операция: Обновление баланса клиента в таблице users\n";
    $logMessage .= "clientId: " . $clientId . ", dolg: " . $dolg . "\n";
    error_log($logMessage, 3, 'logs/vnesenie_v_kasse.log');
    $pdo->commit();
    echo json_encode(['status' => 'success']);
} catch (PDOException $e) {
    $pdo->rollBack();
    echo json_encode(['status' => 'error', 'message' => 'Ошибка: ' . $e->getMessage()]);
}

Добавлено через 6 минут

Сообщение от gena8208

логирование операций но это тоже не защитит от глюков, наверное.

создал логирование ....

@ft4l · 23.01.2025, 18:32

gena8208, как-то можно проверить влияет-ли ?

PHP    
        
    Скопировано
1
ignore_user_abort(1);

Не совсем понял, но думаю такое возможно, если выполняется запрос START TRANSACTION,
какое-то добавление, а потом скрипт просто завершает работу... без COMMIT/ROLLBACK
изначально вроде так и было реализовано

By default, MySQL runs with autocommit mode enabled. This means that as soon as you execute a statement that updates (modifies) a table, MySQL stores the update on disk to make it permanent. To disable autocommit mode, use the following statement:
SET autocommit=0;

... хотя не знаю чего там под капотом pdo, и доки к mysql у меня древние ))

Не по теме:

Как вариант ещё попробовать COMMIT и ROLLBACK в функции где-то реализовать, и зарегистрировать её с

PHP    
        
    Скопировано
1
register_shutdown_function(callable $callback, mixed ...$args): ?bool

Выполнится даже в случае ошибок/прерывания
но тоже костыль, и передавать/получать кучу всего... объект pdo, перевменную какую насчёт всё-ли выполнено

@Jodah · 23.01.2025, 18:36

Сообщение от gena8208

происходит подвисание инета

Надо дебажить, что именно подвисает. Если база - по какой причине? Может не хватает кол-ва одновременных подключений или каких ресурсов.

Сообщение от gena8208

В таблице касса появляется несколько одинаковых записей. А в таблице клиент баланс клиента не обновился

Вообще в скрипте есть стандартная проблема, о которой любят спрашивать на собесах - отсутствие обработки конкурентного доступа. Запускаем скрипт одновременно несколько раз - и каждая транзакция будет параллельно выполнять SELECT + INSERT + UPDATE несмотря на другие транзакции. В итоге UPDATE по сути сработает только один (последний), он перезапишет результат предыдущих апдейтов.

Условно, у юзера баланс 100 рублей. Запускается 2 транзакции, каждая на списание 70 рублей. Каждая видит, что у юзера баланс 100, исходя из этого оформляет покупку и обновляет баланс на 30р. В итоге оформилось 2 заказа суммарно на 140р, а у юзера списалось только 70.

Для решения проблемы используем блокирующее чтение, т.е. SELECT ... FOR UPDATE.

Думаю в вашем случае это вполне может быть оно, т.к. подвисает база, и после отвисания срабатывают сразу несколько транзакций, ожидающих выполнения.

@ft4l · 23.01.2025, 18:40

Не по теме:

Сообщение от ft4l

ignore_user_abort(1)

Хотя там да... тормоза перед тем как php может поймать отмену/прерывание

PHP не обнаружит, что пользователь прервал соединение до тех пор, пока не будет произведена попытка отправки информации клиенту. Простое использование выражения echo не гарантирует отправку информации, смотрите функцию flush().

@Jodah · 23.01.2025, 19:06

Сообщение от gena8208

Она несколько раз жмет кнопку сохранить

К слову, это тоже типовая проблема, решение - ключ идемпотентности.

@gena8208 · 23.01.2025, 20:48 **[ТС]**

Сообщение от Jodah

К слову, это тоже типовая проблема, решение - ключ идемпотентности.

Сообщение от ft4l

Не по теме:

Сообщение от Jodah

Надо дебажить, что именно подвисает. Если база - по какой причине?

База лежит на хостинге рег.ру. Может и у них с сервером проблема. ИИ подсказывает что надо передать переменные на сервер а там производить транзакцию с помощью хранимой процедуры или делать тригеры и проверять операция завершена или нет и еще можно логировать статус операции ... вариантов много, но мне понравился вариант передать переменные на сервер а там производить транзакцию с помощью хранимой процедуры Ведь под самой базой а не через php транзакция либо пройдет либо откатится. Возможно я ошибаюсь. Не настолько спец. Всем спасибо буду думать. Если есть мысли, буду рад ознакомиться

Добавлено через 1 минуту

Сообщение от Jodah

К слову, это тоже типовая проблема, решение - ключ идемпотентности.

про это тоже инфу поищу.

Добавлено через 4 минуты

Сообщение от Jodah

К слову, это тоже типовая проблема, решение - ключ идемпотентности.

Да именно об этом писал ИИ но другими словами. Отличная информация, познавательная. Спасибо

@sad67man · 23.01.2025, 22:15

Сообщение от gena8208

Оператор вносит в кассу сумму. Инет подвис. Видимо (мое предположение)она не дождалась статус что данные внесены или статус обо ошибке. Она несколько раз жмет кнопку сохранить . Потом инет отвисает. В таблице касса появляется несколько одинаковых записей. А в таблице клиент баланс клиента не обновился

1) Запуск одновременно несколько операций над одной записью лучше не допускать, чтоб как раз избегать таких плавающих ошибок... Для этого нужно делать блокировки.
2) Операция должна быть идемпотентна. Чтоб если вы запускали несколько раз одну и туже операцию - в итоге получили один результат, как будто бы выполнили эту операцию один раз. Для этого и необходим ключ идемпотентности.

У вас оба пункта не выполнены.

Сообщение от gena8208

PHP    
        
    Скопировано
1
2
$dolg = (int)$clientData['dolg'] + $sumall;
    $stmt2 = $pdo->prepare("UPDATE users SET dolg = :dolg WHERE id = :id");

Вот тут проблема. Если параллельно запустить несколько операций, то начальный остаток будет одинаков и последняя транзакция затрет баланс. Тут и еще такой подход, что теоретически данные могут разойтись, хорошо когда их можно актуализировать т.е. пересчитать баланс.

@Jodah · 23.01.2025, 23:12

Сообщение от gena8208

База лежит на хостинге рег.ру.

Если это виртуальный хостинг, а не VPS/VDS, то подвисания - норма, т.к. провайдеры обычно не гарантируют постоянный доступ к выделенным ресурсам.

Сообщение от gena8208

передать переменные на сервер а там производить транзакцию с помощью хранимой процедуры

Это не решит проблему.

Сообщение от gena8208

Ведь под самой базой а не через php транзакция либо пройдет либо откатится.

Под PHP она точно также либо пройдёт, либо откатится, в этом смысл транзакций. Выполняются они ведь также в СУБД.

Сообщение от gena8208

Если есть мысли, буду рад ознакомиться

Думается, вы грешите на PHP, дескать он плохо с транзакциями работает. Но нет, проблема архитектурная, а PHP всё делает как надо, просто при множественных запросах вы не видите, как один UPDATE запрос перекрывается другим.

@gena8208 · 26.01.2025, 10:32 **[ТС]**

Сообщение от sad67man

1) Запуск одновременно несколько операций над одной записью лучше не допускать, чтоб как раз избегать таких плавающих ошибок... Для этого нужно делать блокировки.
2) Операция должна быть идемпотентна. Чтоб если вы запускали несколько раз одну и туже операцию - в итоге получили один результат, как будто бы выполнили эту операцию один раз. Для этого и необходим ключ идемпотентности.

С одной записью работает один оператор. Если сделать так, например, когда оператор нажал кнопку сохранить то кнопка сохранить становится неактивной, чтобы транзакция прошла успешно или выдала ошибку что операция не выполнена? Или это не правильный подход?

Сообщение от Jodah

Думается, вы грешите на PHP, дескать он плохо с транзакциями работает. Но нет, проблема архитектурная, а PHP всё делает как надо, просто при множественных запросах вы не видите, как один UPDATE запрос перекрывается другим.

Я это предполагаю. При первом нажатии не было сообщения об успехе или ошибка поскольку инет подвис. Они начали нажимать несколько раз. В итоге первая транзакция не прошла а остальные прошли и баланс несколько раз изменился. Самый простой способ я думаю блокировать кнопку сохранения после первого клика пока транзакция не пройдет успешно или выдаст ошибку. МОжет глупо конечно

Добавлено через 31 секунду

Сообщение от Jodah

Если это виртуальный хостинг, а не VPS/VDS, то подвисания - норма, т.к. провайдеры обычно не гарантируют постоянный доступ к выделенным ресурсам.

Да именно виртуальный хостинг

Добавлено через 5 минут

Сообщение от Jodah

Думается, вы грешите на PHP, дескать он плохо с транзакциями работает. Но нет, проблема архитектурная, а PHP всё делает как надо, просто при множественных запросах вы не видите, как один UPDATE запрос перекрывается другим.

Да именно так я и думал)). Сейчас логирую все транзакции чтобы хоть понять в какой момент что не внеслось и чтобы суммы не терялись. Это пока единичный случай был, но он был. И предполагать я этого не мог, т.к. в первые CRUD через сайт делал. Раньше писал проги на C# дял CRUD. Там проблем с этим не было

Добавлено через 21 минуту

Сообщение от sad67man

Запуск

Сообщение от Jodah

Думается

ИИ подсказал такую вещь. При выполнении транзакции делать прорверку на изменение ячейки. Изменения произошли то транзакция успешна, иначе откат.
Пример

SQL    
        
            
                
                
                
                
            
        
    Скопировано
1
2
3
4
5
6
7
8
9
10
11
12
13
14
START TRANSACTION;
 
UPDATE users
SET name = 'Новое имя', age = 30
WHERE id = 123;
 
-- Проверяем, было ли поле name изменено
SELECT name FROM users WHERE id = 123;
 
IF ROW_COUNT() = 0 THEN
  ROLLBACK;
ELSE
  COMMIT;
END IF;

В примере, который я дал ранее, мы используем команду ROW_COUNT() для проверки, было ли поле name изменено.

ROW_COUNT() возвращает количество строк, затронутых последней операцией UPDATE или DELETE. Если поле name не было изменено, то ни одна строка не будет затронута, и ROW_COUNT() вернет 0. Если поле name было изменено, то по крайней мере одна строка будет затронута, и ROW_COUNT() вернет 1 или больше.

Поэтому, в примере, мы проверяем, равен ли результат ROW_COUNT() 0. Если он равен 0, это означает, что поле name не было изменено, и мы откатываем транзакцию. Если он не равен 0, это означает, что поле name было изменено, и мы подтверждаем транзакцию.

Таким образом, мы проверяем, было ли поле name изменено, не сравнивая старое и новое значения явно, а просто проверяя, было ли затронуто хотя бы одна строка операцией UPDATE.

Что скажете?

@ft4l · 26.01.2025, 11:10

Сообщение от gena8208

Что скажете?

Сессии.
Когда для пользователя выполняется скрипт, который открыл сессию, файл сессии блокируется ,
и открытия сессии, с таким-же сид, ожидают разблокирования
... по завершению первого, или по выполнению из него session_write_close() или подобного .
Также частоту выполнения можно ограничить, сохранением и проверкой времени успешного выполнения,
касательно выполнения какого-либо действия конкретно.

@Jodah · 26.01.2025, 13:44

Сообщение от gena8208

первая транзакция не прошла

Но новые записи добавились, значит транзакции прошли.

Сообщение от gena8208

МОжет глупо конечно

Нормальное решение, чтобы юзер не мог спамить запросами. Только подозреваю, что проблему это не решит, т.к. есть подвисания, после которых могут начать выполняться сразу несколько запросов от разных операторов.

Сообщение от gena8208

Что скажете?

ИИ предложил дичь. Проблема типовая и её решение тоже типовое - SELECT ... FOR UPDATE, благодаря чему транзакции будут отрабатывать поочерёдно, не перекрывая друг друга. Больше тут ничего не требуется.

Новые блоги и статьи Все статьи Все блоги /
Не удержался от оценки концепции двигателя Стирлинга. Hrethgir 03.04.2025 Сколько не пытался - она выдавала правильные схемы, причём случайно рисовала горячие области в середине, холодные по краям, трубки с краёв в низ и магнит в соединяющей, но при этой выдавала описание. . .	Метод с двумя буферами (или double buffering) или ping-pong buffering Hrethgir 02.04.2025 Из ответов LM модели. Метод, который предполагает использование двух массивов для хранения промежуточных результатов сложения векторов, обычно применяется в сценариях, где необходимо минимизировать. . .	На любовном киберфронте Alexander-7 01.04.2025 Недавно на одном малоизвестном сайте знакомств мною заинтересовалась девушка: «Текст немного странный. Но, судя по адресу почты, иностранка», – подумал я. Поколебавшись пару суток, я ответил ей:. . .	Как работает Node.js изнутри run.dev 29.03.2025 Node. js изменил подход к разработке веб-приложений, позволив использовать JavaScript не только на стороне клиента, но и на сервере. Созданный в 2009 году Райаном Далем, этот открытый,. . .	Моки в Python: Mock Object Library py-thonny 29.03.2025 Тестирование кода требует особого подхода, когда речь идёт о компонентах, взаимодействующих с внешним миром. Мы часто сталкиваемся с непредсказуемостью HTTP-запросов, чтением данных из базы или. . .
JavaScript: Управление памятью и улучшение производительности run.dev 29.03.2025 В отличие от низкоуровневых языков программирования, JavaScript не требует ручного выделения и освобождения памяти. Здесь работает автоматический сборщик мусора, который определяет, какие объекты. . .	Мультитенантная архитектура со SpringBoot и PostgreSQL ArchitectMsa 29.03.2025 SaaS-приложения редко обслуживают одного клиента и обычно они должны поддерживать множество организаций, каждая из которых работает в своём изолированном пространстве. Мультитенантная архитектура. . .	std::span в C++: Производительность и лучшие практики NullReferenced 28.03.2025 std::span — одно из самых недооценённых нововведений стандарта C++20, которое радикально меняет подход к работе с непрерывными последовательностями данных. По сути, это невладеющее представление. . .	Многопоточность в C#: Threadpool UnmanagedCoder 28.03.2025 Пул потоков в C# — это коллекция заранее созданных и готовых к использованию потоков, которые находятся в распоряжении приложения. Вместо того чтобы создавать и уничтожать потоки для каждой небольшой. . .	Вопросы на собеседованиях по микросервисам ArchitectMsa 27.03.2025 Работодатели ищут не просто разработчиков, знающих базовые концепции, а специалистов, разбирающихся в тонкостях масштабирования, отказоустойчивости и производительности. Сейчас на первый план выходят. . .

quwy Native x86 6450 / 3553 / 994 Регистрация: 13.02.2013 Сообщений: 11,265
	22.01.2025, 19:26
	БД какая? Не все базы (и не все движки в некоторых базах) поддерживают транзакции. 0

@gena8208 4 / 4 / 1 Регистрация: 20.12.2019 Сообщений: 310
	23.01.2025, 17:20 [ТС]
	Сообщение от quwy БД какая? Не все базы (и не все движки в некоторых базах) поддерживают транзакции. Mysql InnoDB 0

quwy Native x86 6450 / 3553 / 994 Регистрация: 13.02.2013 Сообщений: 11,265
	23.01.2025, 17:57
	Сообщение от gena8208 Mysql InnoDB Он-то транзакции поддерживает, но вы как-то не правильно представляете себе работу серверных скриптов. Сообщение от gena8208 Во время работы транзакции происходит подвисание инета "Подвисание интернета" на работу PHP-скрипта влияет весьма опосредственно. Не прервется скрипт мгновенно при пропадании связи с клиентом. На "осознание" проблемы сетевому стеку нужно как минимум несколько секунд (или даже десятков секунд). Причем это время должно пройти пока открыта транзакция. В коде у вас все выглядит правильно, но проблема скорее всего в другом месте. 0

@Jodah 3886 / 3226 / 1351 Регистрация: 01.08.2012 Сообщений: 10,878
	23.01.2025, 18:36
	Сообщение от gena8208 происходит подвисание инета Надо дебажить, что именно подвисает. Если база - по какой причине? Может не хватает кол-ва одновременных подключений или каких ресурсов. Сообщение от gena8208 В таблице касса появляется несколько одинаковых записей. А в таблице клиент баланс клиента не обновился Вообще в скрипте есть стандартная проблема, о которой любят спрашивать на собесах - отсутствие обработки конкурентного доступа. Запускаем скрипт одновременно несколько раз - и каждая транзакция будет параллельно выполнять SELECT + INSERT + UPDATE несмотря на другие транзакции. В итоге UPDATE по сути сработает только один (последний), он перезапишет результат предыдущих апдейтов. Условно, у юзера баланс 100 рублей. Запускается 2 транзакции, каждая на списание 70 рублей. Каждая видит, что у юзера баланс 100, исходя из этого оформляет покупку и обновляет баланс на 30р. В итоге оформилось 2 заказа суммарно на 140р, а у юзера списалось только 70. Для решения проблемы используем блокирующее чтение, т.е. SELECT ... FOR UPDATE. Думаю в вашем случае это вполне может быть оно, т.к. подвисает база, и после отвисания срабатывают сразу несколько транзакций, ожидающих выполнения. 1

@ft4l
	23.01.2025, 18:40
	Не по теме: Сообщение от ft4l ignore_user_abort(1) Хотя там да... тормоза перед тем как php может поймать отмену/прерывание PHP не обнаружит, что пользователь прервал соединение до тех пор, пока не будет произведена попытка отправки информации клиенту. Простое использование выражения echo не гарантирует отправку информации, смотрите функцию flush(). 0

@Jodah 3886 / 3226 / 1351 Регистрация: 01.08.2012 Сообщений: 10,878
	23.01.2025, 19:06
	Сообщение от gena8208 Она несколько раз жмет кнопку сохранить К слову, это тоже типовая проблема, решение - ключ идемпотентности. 1

@gena8208 4 / 4 / 1 Регистрация: 20.12.2019 Сообщений: 310
	23.01.2025, 20:48 [ТС]
	Сообщение от Jodah К слову, это тоже типовая проблема, решение - ключ идемпотентности. Сообщение от ft4l Не по теме: Сообщение от Jodah Надо дебажить, что именно подвисает. Если база - по какой причине? База лежит на хостинге рег.ру. Может и у них с сервером проблема. ИИ подсказывает что надо передать переменные на сервер а там производить транзакцию с помощью хранимой процедуры или делать тригеры и проверять операция завершена или нет и еще можно логировать статус операции ... вариантов много, но мне понравился вариант передать переменные на сервер а там производить транзакцию с помощью хранимой процедуры Ведь под самой базой а не через php транзакция либо пройдет либо откатится. Возможно я ошибаюсь. Не настолько спец. Всем спасибо буду думать. Если есть мысли, буду рад ознакомиться Добавлено через 1 минуту Сообщение от Jodah К слову, это тоже типовая проблема, решение - ключ идемпотентности. про это тоже инфу поищу. Добавлено через 4 минуты Сообщение от Jodah К слову, это тоже типовая проблема, решение - ключ идемпотентности. Да именно об этом писал ИИ но другими словами. Отличная информация, познавательная. Спасибо 0

@Jodah 3886 / 3226 / 1351 Регистрация: 01.08.2012 Сообщений: 10,878
	23.01.2025, 23:12
	Сообщение от gena8208 База лежит на хостинге рег.ру. Если это виртуальный хостинг, а не VPS/VDS, то подвисания - норма, т.к. провайдеры обычно не гарантируют постоянный доступ к выделенным ресурсам. Сообщение от gena8208 передать переменные на сервер а там производить транзакцию с помощью хранимой процедуры Это не решит проблему. Сообщение от gena8208 Ведь под самой базой а не через php транзакция либо пройдет либо откатится. Под PHP она точно также либо пройдёт, либо откатится, в этом смысл транзакций. Выполняются они ведь также в СУБД. Сообщение от gena8208 Если есть мысли, буду рад ознакомиться Думается, вы грешите на PHP, дескать он плохо с транзакциями работает. Но нет, проблема архитектурная, а PHP всё делает как надо, просто при множественных запросах вы не видите, как один UPDATE запрос перекрывается другим. 0

@ft4l Невнимательный 2810 / 1146 / 353 Регистрация: 08.02.2013 Сообщений: 6,548 Записей в блоге: 2
	26.01.2025, 11:10
	Сообщение от gena8208 Что скажете? Сессии. Когда для пользователя выполняется скрипт, который открыл сессию, файл сессии блокируется , и открытия сессии, с таким-же сид, ожидают разблокирования ... по завершению первого, или по выполнению из него session_write_close() или подобного . Также частоту выполнения можно ограничить, сохранением и проверкой времени успешного выполнения, касательно выполнения какого-либо действия конкретно. 0

@Jodah 3886 / 3226 / 1351 Регистрация: 01.08.2012 Сообщений: 10,878
	26.01.2025, 13:44
	Сообщение от gena8208 первая транзакция не прошла Но новые записи добавились, значит транзакции прошли. Сообщение от gena8208 МОжет глупо конечно Нормальное решение, чтобы юзер не мог спамить запросами. Только подозреваю, что проблему это не решит, т.к. есть подвисания, после которых могут начать выполняться сразу несколько запросов от разных операторов. Сообщение от gena8208 Что скажете? ИИ предложил дичь. Проблема типовая и её решение тоже типовое - SELECT ... FOR UPDATE, благодаря чему транзакции будут отрабатывать поочерёдно, не перекрывая друг друга. Больше тут ничего не требуется. 0