Критическая секция в РБД

[Winexcel]

Всем доброго времени суток!
Не давно начал изучать sql, читаю Мартина Грабера за 2014, и задался таким вопросом, а как же синхронизировать рбд, в книге нашёл информацию только о блокировках, но конкретных примеров этого нет, кто может, подскажите как оптимизировать запрос UPDATE с синхронизацией(говорю так потому что не знаю как правильно это называется в sql, возможно угадал )

[Vapaamies]

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

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

Это что-то новенькое.

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

Взаимодействие транзакций из разных сеансов описывается уровнями изоляции транзакций, их обозначают аббревиатурой ACID. Почитай в Википедии. Не помню, описывается это у Грабера или нет.

Реализация транзакций зависит от конкретной СУБД. В стандарте SQL предусмотрены команды select for update, commit и rollback, они должны быть реализованы в любой СУБД. Каждая СУБД может иметь дополнительные команды для управления транзакциями, но стандарта на них нет.

Я угадал с ответом?

[Stilet]

Я угадал с ответом?

Как по мне угадал на 100%. По крайней мере на базе SQL сопроцессов нет а значит и синхронизация не актуальна, хотя некоторые СУБД умудряются зарулить на других языках типа Java (Оракл) такие вещи.
И было бы неплохо узнать откуда ноги растут у сего вопроса.

[Winexcel]

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

Как по мне угадал на 100%. По крайней мере на базе SQL сопроцессов нет а значит и синхронизация не актуальна, хотя некоторые СУБД умудряются зарулить на других языках типа Java (Оракл) такие вещи.
И было бы неплохо узнать откуда ноги растут у сего вопроса.

А ноги растут вот откуда : я собираюсь писать клиент-серверное приложение, где допустим в онлайне на данный момент находится 100 человек, на сервере есть скрипт в котором есть поиск игры, и этот скрипт выводит в поиске например игру с 10тью слотами для игры, когда человек входит в данный слот в БД некое поле COUNT = COUNT + 1( это на sql запросе) вот это и есть запись UPDATE, но случается такое иногда что если одновременно около 30 человек будут стучатся в данную игру со слотами, происходит переполнение, ну например 12 человек зашло в игру где всего 10 слотов. Вот и интересно как бы это решить.

[Vapaamies]

В СУБД подобные задачи решаются добавлением записей в таблицу сеансов и контроля либо одновременного количества записей в таблице, либо количества активных записей (что-то вроде очереди).

[Winexcel]

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

В СУБД подобные задачи решаются добавлением записей в таблицу сеансов и контроля либо одновременного количества записей в таблице, либо количества активных записей (что-то вроде очереди).

Я читал http://habrahabr.ru/post/137979/ , вот это поможет? Я прост новичок в sql, на данный момент только связанные подзапросы изучаю

[Winexcel]

Вот к примеру есть запрос:

UPDATE wow_game
SET Num_People = Num_People +1
WHERE id = 1

id тут есть игра, Num_People = кол-во людей в слотах, есть отдельное поле COUNT в котором указывается сколько всего есть слотов, на пхп я использую SELECT и сравниваю оба эти поля, если поле Num_People < COUNT то мы делаем UPDATE, дак вот если просто заблокировать то поле полностью, даже сделать недоступным для READ_ONLY, то тогда думаю выйдет что-то путёвое, или заставить PHP ждать ответа от БД.

[Vapaamies]

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

Я читал http://habrahabr.ru/post/137979/ , вот это поможет?

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

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

когда человек входит в данный слот в БД некое поле COUNT = COUNT + 1( это на sql запросе) вот это и есть запись UPDATE

Должно быть примерно так:

insert into game_sessions
  (game_id, session_id)
select
  :game_id, :session_id -- передаются как параметры
where
  (select count(*) from game_sessions where game_id = :game_id) <= 10;

Тут проверка и добавление делаются за один шаг, что транзакционно безопасно и должно держать большую нагрузку. Была ли вставлена запись, можно узнать средствами API сервера, что-то вроде SQL%rowcount или "affected rows".

Подразумевается, что пользователь помнит session_id в пользовательском окружении (на сервере или на клиенте), а при выходе из игры запись удаляется. Можно хранить историю всех сеансов, для чего ввести поле active и проверять его в подзапросе.