Как НЕ фиксировать транзакцию после отработки php скрипта?

Question

[Тяги Тяги]

Доброго,
Есть php скрипт, который выполняет пользовательский запрос $_POST['SQL'].

Мне необходимо, чтобы при определенных параметрах, после отработки скрипта, данный запрос не фиксировался и дожидался соответстветствующей команды через неопределённое кол-во времени.

Т.е., условно, создаю запись в таблице А, делаю манипуляции на стороне клиента и сажаю на данную запись в таблицу Б другие записи / либо не сажаю, и, соответственно делаю откат (пример бессмысленный, но суть есть)

Есть какие-то примеры данного "фокуса"?

Comments

[Дмитрий]

https://www.php.net/manual/ru/pdo.commit.php

[Stalker_RED]

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

Answer 1

[Stalker_RED]

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

Про сажаю/не сажаю вообще непонятно о чем речь.

Comments

[Тяги Тяги]

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

Т.е., проблема в том, что сначала создается мероприятие, а затем, в него поштучно записываются люди из этой самой таблицы. (не знаю, как это написать формально =) )

Какой-то человек может по какой-либо причине не записаться и мне нужно будет делать откат всего мероприятия.

Спасибо за примеры, посмотрю позднее

[Александр Маджугин]

садится - это какое-то новой словечко, распространенное среди СЕОшников и джунов, обозначающее записывается, сохраняется. В данном случае видимо сохраняется в консистентном состоянии.

Почти уверен что вы правы и это из цикла "незавершенная регистрация". Сам хотел ответить что-то похожее что вы написали.

[aryzhanki]

komino, тут скорее не таблица нужна вторая, а столбец с флагами - участвует/не участвует

а если и две таблы, то зачем переносит все данные, таблица А будет базовой, а таблица участников Б будет содержать только айдишник участника из таблицы А, оттуда же по айдишнику из Б выбираем данные участника

[Тяги Тяги]

aryzhanki, бд от организации, на структуру влиять не могу

[aryzhanki]

komino, ну тогда в ответе читайте второй абзац

Answer 2

[alexalexes]

$_POST['SQL'];
Ой, вы доверяете клиенту настолько, что позволяете ему самому формировать текст запроса для бэкенда?
У такой модели взаимодействия уровень безопасности еще ниже, чем у подготовленных запросов со строковой склейкой параметров.
Идеология выполнения скриптов в PHP такая, чтобы выполнить все атомарные действия, зафиксировать результат (или откатиться), отдать ответ и умереть.

Есть какие-то примеры данного "фокуса"?

Есть. Технология называется web sockets, она представляет другую идеологию - называется длинные запросы. Когда клиент открывает соединение с сервером и ждет от сервера сообщений (или сам их отправляет в соккет), при этом скрипт сервера в бесконечном цикле опрашивает открытый соккет. Не завершая скрипт, на сервере можно либо ожидать появление сообщения в соккете, либо выполнять что-то по транзакции, если имеется принятое сообщение.
Проблема еще в том, что PHP не сильно приспособлен для этого режима. Вам придется делать бесконечную петлю обработки в скрипте:

while(true)
{
  // исполняемый код для всех клиентов соккетов
}

И вам нужно самим делать механизм сессий, чтобы отличать одного клиента от другого, поскольку запущенный скрипт будет принимать сообщения от всех клиентов.
Для этих целей больше годится NodeJS. Там все соккеты разбиты по обработчикам событий, можно выделить контекст одного конкретного клиента.
Резюмируя, могу сказать.
а) Вы пишите свой продвинутый редактор запросов (а-ля PHPMyAdmin но с поддержкой транзакций) и у вас неправильно выбран вид сервера для бэкенда (PHP вместо NodeJS). Технические требования для взаимодействия клиента и сервера не имеют подходящей реализации технологии на сервере (web sockets).
б) Либо у вас приложение не предполагает работы, связанной с редактированием запросов пользователем. Вы просто переносите опыт разработки desktop приложений на веб разработку.
В этом случае вы не правильно делаете то, что формируете запросы на клиенте. Толстую бизнес-логику, предполагающую взаимодействие с базой данных с фиксацией или не фиксацией транзакции нужно переносить на бэкенд, либо в хранимые процедуры и функции СУБД.

Comments

[Тяги Тяги]

согласен, сейчас в моем приложении используя devtools можно натворить много делов..

Я делаю инструмент для формирования типовых таблиц с возможностью редактирования данных.

Конкретно в этом примере, все происходит при нажатии на кнопку в таблице.
Запускается функция, которая на вход принимает запрос и отправляет его дальше ajax'ом.

В плане разработки я ограничен JavaScript + JQuery + PHP.

Как это защитить?

[alexalexes]

Значит, все таки у вас вариант А. Вы делаете продвинутый редактор для админки.
В этом случае, с точки зрения безопасности, если набор прав профиля пользователя админки (он же администратора) имеет ту же полноту набора прав роли пользователя базы данных, под которым он соединяется с базой, то не имеет значения, будет ли этот пользователь пытаться сделать sql-инъекции к базе с которой он работает или нет. Он все равно не превысит свои права доступа, что разрешено ролью в базе.
Главное, не оставляйте такой механизм взаимодействия для обычных посетителей сайта, где их права ограничиваются не ролью в учетке СУБД, а бизнес-логикой.

Конкретно в этом примере, все происходит при нажатии на кнопку в таблице.
Запускается функция, которая на вход принимает запрос и отправляет его дальше ajax'ом.

Значит, когда вам нужно выполнить что-то, что требует включения режима транзакции и удержания его в реальном времени, в этой ситуации вам нужно общаться с сервером не по ajax, а через web socket. Подключаясь к отдельному php скрипту, сервер которого работает в особом режиме сессий (общие сессии), настройки сервера не должны завершать скрипт по таймауту (или делать его продолжительность в несколько часов - в пределах жизни сессии администратора), а код скрипта должен работать в бесконечной петле.