Добрый день!

Снова со своими вопросами.  Сорри, не очень придумал как топик назвать.

Вот предположим, есть движок форума. В нем функция, принимающая ответ в тему. Нужно проверить входящие данные, тра-та-та, и есть еще целый ряд прав на действие. Например, нельзя постить ответ в закрытую тему. Обычно изначально выбираются данные из БД, и потом идет проверка на языке движка форума а-ля if ($result['closed'] == 0)... А бывает идет запрос с условием вида closed=0, и т.д.... Суть в том, что мы сначала проверяем возможность/допустимость добавления ответа в тему, а лишь затем приступаем непосредственно к самому добавлению. Очевидно, что в промежутке между такой проверкой и собственно самим добавлением ответа в тему, эта тема вполне может быть закрыта.

Конечно, в случае с форумом такое крайне маловероятно, и даже если произойдет - это вообще ерунда. Но форум тут число дли наглядной иллюстрации сути вопроса.

В общем, как быть в такой ситуации, когда мы имеем дело со вставкой / изменением / удалением данных в БД, когда возможность данной операции определяется некоторыми значениями в некоторых таблицах этой БД, и мы хотим быть уверенными в целостности структуры БД после выполнения таких действий?

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

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

Ну и самое время вспомнить о транзакциях. Или, в простейшем варианте, SELECT ... FOR UPDATE.

Для обеспечения согласованности данных в конкурентной среде используют механизмы:
1) Ограничения целостности
2) Уровни изоляции транзакций.
3) Явные блокировки
Ранжировано в порядке предпочтительности. Там, где можно отжаться констрейтами, лучше отжиматься ими, если нет, пробовать отжаться изоляцией, если и тут нет - выстраивать стратегию блокирования самостоятельно.

Akina, блин, ну неудачный пример, хотите придумаю другой - вместо добавления нового поста, пусть запрос на сохранение при редактировании существующего. очевидно, что после закрытия темы, никаких редактирований ее постов уже не стоит допускать. Суть не в примере, а в вопросе. По SELECT ... FOR UPDATE спасибо, сейчас буду читать.


Zloxa, спасибо, но вообще ничего не понял. 

В таком случае заодно почитай про REPLACE.

Не вспомнить а узнать!  Юзаю MyISAM и переходить на всякие-там InnoDB только ради транзакций в ближайшем времени не планирую.

Так что пока смотрю в сторону блокировки таблицы средствами СУБД. Всякие поля типа locked для блокировки строк считаю стремными велосипедами.

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

Про него знаю конечно.  Но какое он имеет отношение к теме - не пойму?

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

https://habrahabr.ru/post/46542/
тут пишут:



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

http://ru.stackoverflow.com/questions/3948...%B5-lock-tables
а вот тут в комментарии:


к коду:



А разве данные будут одинаковыми?

Я только начинают изучать блокировки. Но насколько понимаю, если поставить LOCK TABLES WRITE, параллельный вызов скрипта "зависнет" на первой строке (LOCK TABLES), будет ждать пока таблица станет доступна для блокировки (закроется текущая блокировка, закончится очередь), и только после этого будет выполняться SELECT во второй строчке... Или нет?  

Стоп... это я на автомате. SELECT FOR UNDATE и INSERT ON DUPLICATE попутались.

Akina, по предыдущему моему сообщению можете дать комментарии? Мне это важно.

Автор не ошибся. Действительно надо перечислять всё-всё. 

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

Да, именно так. Попробуйте самостоятельно на такой же простой модели, но с 2 копиями клиента - увидите.
Вот только НАСТОЯТЕЛЬНО рекомендую явно указывать требуемые локи (по отдельности), причём строго в соответствии с документацией - сначала на запись, потом на чтение. Т.е. не 
а 

Akina, круто, благодарю за доходчивые пояснения!  

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

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

Это сообщение отредактировал(а) Zloxa - 8.12.2016, 12:04

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

Да и среда там конкурентная, но не высоко конкурентная. Т.е. надо заботиться о целостности данных. Но блокировка всей таблицы не является критической штукой. Как-то так...

  а где можно накосячить в простейшем запросе 
???

Akina, но ведь между этими системами хранения есть отличия, которые надо учитывать. Готовый большой проект, все работает на MyISAM. Если просто поменять MyISAM -> InnoDB, 100% полезут глюки, надо учитывать структуру БД, запросы, логику...

Добавлено через 5 минут и 20 секунд
Навскидку вот такой даже примитив https://habrahabr.ru/post/156489/ и уверен есть куча подводных камней. А опыта работы с InnoDB у меня 15 минут. 

Есть один проект, там CMS самописная (не моя) простая небольшая. Стоит на VPS, который быстренько поднял с полностью чистого образа. Проект небольшой, нагрузка - слезы. Через неделю после поднятия начались глюки - БД висла. Нагрузка минимальная, top показывает avg. 0.05 примерно - чтоб понимали. Начал копаться. Кароче там какой-то баг был из-за того, что в системе не было своп-файла. Так там нагрузка минимальна, 2Гб ОЗУ - зачем своп??? Подключил своп 2Гб, эти глюки пропали. Со временем появились новые. Уже не помню что там было, копался-копался, исправил. Потом еще что-то. Теперь опять БД временами виснет. Почему - непонятно. С MyISAM таких проблем нет. Примитивно, просто, но хорошо.