sda писал(а):zelenin, нет мьютексы могут помочь только в очень узком кругу задач, например при регистрации на сайте. Но в других местах системы от них нет никакого толка, именно из-за обилия вариантов, которые можно по разному сочетать друг с другом, вот так например:
и? не хватает отлова исключения, применяем мьютексы. Нужно много мьютексов? Делаем много.
sda писал(а):
Даже если есть мьютексы на create-game и на join-game, то в этом случае они не остановят хакера и он сможет создать заявку на игру и присоединиться к своей же заявке, что явно нарушает логику работы программы. Таких конфликтных вариантов сочетания запросов в сложном проекте может быть десятки и даже сотни. Поэтому мьютексы не подойдут, я найду множество различных вариантов, которые сломают всю логику в сложном интерактивном проекте, при помощи конкурентных запросов, как бы они не обкладывали свой проект мьютексами.
еще раз: разделяйте разные задачи. конкурентные запросы и ограничение запросов - разные вещи, решаемые различными методами.
Все примеры, которые я привожу - это исключительно конкурентные запросы. В каждом сообщении пишу, что логика программы может легко сломаться, тогда когда на сервер приходит 2 одновременных (конкурентных) запроса. Не было бы конкурентных запросов - не сущестовавало бы и проблемы и соответственно этой темы. Большинство (если не все) сайты на yii имеют эту проблему и официальный темплейт от разработчиков тоже.
последний раз повторю: проблема "1 раза в 3 минуты" - это проблема фильтра. То, что фильтрация может сломаться из-за конкурентных запросов - проблема конкурентных запросов. Для первой проблемы делаем фильтр, для второй внедряем в фильтр мьютексы.
>Я вижу единственное надежное решение, для create-game, join-game и подобных фич, это лок на пользовательские данные с помощью SELECT FOR UPDATE в самом начале транзакции и только затем валидация данных.
нуну, пока один вступает в игру, другой не сможет
>
С регистрацией конечно так не получится, потому что никаких данных в бд еще нет и соответственно лок ставить не на что. Здесь я воспользуюсь отловом исключения, в котором буду повторно вызывать функцию регистрации.
что лочить в новой записи? че за бред вы тут несете
lynicidn писал(а):>
С регистрацией конечно так не получится, потому что никаких данных в бд еще нет и соответственно лок ставить не на что. Здесь я воспользуюсь отловом исключения, в котором буду повторно вызывать функцию регистрации.
что лочить в новой записи? че за бред вы тут несете
Есть ощущение, что вы читаете сообщения через слово. Не только в этой теме. Например в процитированом вами сообщении об этом и было сказано, что в новой записи нечего лочить (то есть невозможно).
zelenin писал(а):
последний раз повторю: проблема "1 раза в 3 минуты" - это проблема фильтра. То, что фильтрация может сломаться из-за конкурентных запросов - проблема конкурентных запросов. Для первой проблемы делаем фильтр, для второй внедряем в фильтр мьютексы.
Да, спасибо. Неправильно сформулировал задачу. Строго говоря, там не "раз в 3 минуты", а возможность создать новую заявку, при условии, что пользователь на текущий момент не участвует ни в какой другой. Просто хотел донести мысль, что в такой ситуации нельзя сделать уникальное поле в таблице заявок, чтобы конкурентный запрос отваливался с экзепшеном, как при регистрации например.
zelenin писал(а):
последний раз повторю: проблема "1 раза в 3 минуты" - это проблема фильтра. То, что фильтрация может сломаться из-за конкурентных запросов - проблема конкурентных запросов. Для первой проблемы делаем фильтр, для второй внедряем в фильтр мьютексы.
Да, спасибо. Неправильно сформулировал задачу. Строго говоря, там не "раз в 3 минуты", а возможность создать новую заявку, при условии, что пользователь на текущий момент не участвует ни в какой другой. Просто хотел донести мысль, что в такой ситуации нельзя сделать уникальное поле в таблице заявок, чтобы конкурентный запрос отваливался с экзепшеном, как при регистрации например.
и это ничего не меняет. Это ровно та же проблема, требующая фильтра.
zelenin, я понял. У меня это не фильтром сделано, а правилом валидации, но особой разницы нет. И в том и в другом случае, нужны мьютексы, как вы верно заметили. Вы не знаете mysqlmutex будет продолжать верно работать если к примеру сделать master-slave репликацию?