Как в PHP запретить выполнение двух одновременных запросов

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

Какое решение есть для запрета выполнения запросов в БД?

---------- Добавлено в 03:02 ---------- Предыдущее сообщение было в 03:01 ----------

Просто походу MySQL сервер тут не причем раз создаются два запроса в микросекундах

по-хорошему, уменьшени баланса должно происходить тогда, когда выплата прошла успешно,

таким образом, логично размещать вызов к ХМЛ интерфейсу в атомарной операции - между локом и анлоком. Но такого делать нельзя - не буду вдаваться в подробности и узкие места такого решения.

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

1. атомарная операция, минусующая баланс и создающая заявку на выплату.

2. демон, периодически проверяющий наличие заявок на выплату и проводящий выплаты (это можно делать даже ежеминутно. клиент не опухнет, если вместо 5 секунд подождет 50)

ну или если без очереди заявок делать,

то в любом случае атомарная операция минусования баланса, если что-то минусанулось, то эта сумма и уходит на выплату. Запрос к ХМЛ в любом случае должен быть вне лока таблиц.

Решение с очередью вам позволяет записывать результаты выплат и в случае сбоев легко иправлять проблемы. Без очереди вам прийдется колупать историю в кипере и сверять вручную, если вдруг где был сбой.

goodier, спрошу еще раз. Почему вы используете

Вместо WHERE `login`= ... ? Зачем вам полнотекстовый поиск по базе?

А по логике проведения выплат dkameleon всё крайне доходчиво объяснил, на мой взгляд.

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

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

PS я всегда считал что "пошлите денег на волшебный кошелек и получите в два раза больше" - это развод, но глядя на этот код уже так не считаю...

iopiop,

Использую конструкцию WHERE login LIKE $login потому, что пользователь один и тодже вводит свой логин маленькими и иногда большими буквами.

palladin_jedi,

Покажите дырки в моем примере пожалуйста.

Вы используете данные, которые вводит пользователь без экранирования и приведения к общему виду?

При таких операциях использование LIKE само по себе - дырка. Сравните скорость выборки вашим выражением и выражением через WHERE = ... Посмотрите на время выполнения.

like и case-sensivity абсолютно никак не связаны. case-sensivity задается при создании таблицы. если у вас collation выставлен c case-sensitive, то like будет учитывать регистр так же как и = . если колонка создана case-insensitive , то опять же поведение что like, что = будет одинаковым и регистр не будет учитываться. читайте документацию, разделC.5.5.1. Case Sensitivity in String Searches

Даже если вы все это не знали, что мешает привести логон в нижний регистр и сравнивать с приведенными в нижний же регистр данными из базы данных?

А теперь представьте что у вас есть пользователи vasya и vas% . что вернет ваш like когда пользователь vas% будет проводить платеж?

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

С добрым утром. Вы когда создаёте таблицу, там есть её настройка в виде кодировки, почитайте каждое название в списке. Явно у вас там написано:

название_кодировки_ci

Вот ci означает, что все данные в таблице регистроНЕзависимые уже по-умолчанию.

спасибо, не знал

$summa = $_POST***91;'Указанная сумма в форме'***93;; 
...
    mysql_query("UPDATE `USERS_table` SET balance=balance-".$summa." WHERE `login` LIKE '".$login."'"); 
 

передача переменной из пост без обработки прямо в запрос -- открытая почва для sql-инъекций