Нагрузка на условие (race condition)

[cWdop]

Здравствуйте,
есть скрипт который реализует продажу билетов в кино

if ($placeRepository->isPlaceFree($placeNumber, $dateFrom, $dateTo)) {
   $placeRepository->book($placeNumber, $dateFrom, $dateTo)
} else {
   throw new Exception(‘The place is already booked!’);
}

Скажите пожалуйста что может произойти при большом числе одновременных запросов?

 

[c0dex]

Сервер сгорит.

 

[cWdop]

А если серьезно, представьте условие одно, а запросов много (фильм жутко интересный), по какому принципу будет срабатывать условие? Один запрос обработает другой, третий и т.д. на это же время уходит, а как быть если поток большой. Как работают высоко нагруженные проекты?

 

[Hello]

@cWdop, https://ru.wikipedia.org/wiki/Состояние_гонки

 

[c0dex]

@cWdop, если серьезно, то надо учиться решать проблемы постепенно. Мы ведь не знаем, что у тебя сокрыто в самом коде. Можешь получить и race condition, а можешь и не получить. Может быть еще до того, у тебя база не будет справляться с потоком запросов, если на ней не будет индексов.

 

[Redjik]

SELECT FOR UPDATE

 

[Вурдалак]

$placeRepository->book($placeNumber, $dateFrom, $dateTo)

Glorified http://martinfowler.com/eaaCatalog/transactionScript.html?

 

[cWdop]

Glorified http://martinfowler.com/eaaCatalog/transactionScript.html?

если я правильно понял, смысл шаблона Transaction Script это получение быстрого результата, к примеру нужно добавить данные в таблицу, пишем код для добавления, нужно удалить, пишем код удаления, если это так, тогда чем данный шаблон хорош при большом количестве запросов

 

[Вурдалак]

если я правильно понял, смысл шаблона Transaction Script это получение быстрого результата, к примеру нужно добавить данные в таблицу, пишем код для добавления, нужно удалить, пишем код удаления, если это так, тогда чем данный шаблон хорош при большом количестве запросов

Твой $placeRepository и есть самый обычный transaction script. Зачем называть это репозиторием — не очень ясно.

 

[cWdop]

Вот популярное решение - http://phpclub.ru/talk/threads/Состояние-гонки.61642/

 

[cWdop]

Обычно нет необходимости блокировать таблицы, поскольку все единичные команды UPDATE являются неделимыми; никакой другой поток не может взаимодействовать с какой-либо SQL-командой, выполняемой в данное время. Однако в некоторых случаях предпочтительно тем или иным образом осуществлять блокировку таблиц:

• Если предполагается выполнить большое количество операций на группе взаимосвязанных таблиц, то быстрее всего это сделать, блокировав таблицы, которые вы собираетесь использовать. Конечно, это имеет свою обратную сторону, поскольку никакой другой поток управления не может обновить таблицу с блокировкой READ или прочитать таблицу с блокировкой WRITE. При блокировке LOCK TABLES операции выполняются быстрее потому, что в этом случае MySQL не производит запись на диск содержимого кэша ключей для заблокированных таблиц, пока не будет вызвана команда UNLOCK TABLES (обычно кэш ключей записывается на диск после каждой SQL-команды). Применение LOCK TABLES увеличивает скорость записи/обновления/удаления в таблицах типа MyISAM.
• Если вы используете таблицы, не поддерживающие транзакций, то при использовании программы обработки таблиц необходимо применять команду LOCK TABLES для гарантии, что никакой другой поток не вклинился между операциями SELECT и UPDATE. Ниже показан пример, требующий использования LOCK TABLES для успешного выполнения операций:
  mysql> LOCK TABLES trans READ, customer WRITE;
  mysql> SELECT SUM(value) FROM trans WHERE customer_id=some_id;
  mysql> UPDATE customer SET total_value=sum_from_previous_statement
  WHERE customer_id=some_id;
  mysql> UNLOCK TABLES;
  
  Без использования LOCK TABLES существует вероятность того, что какой-либо иной поток управления может вставить новую строку в таблицу trans между выполнением операций SELECT и UPDATE.
  
  Поподробнее здесь - http://www.mysql.ru/docs/man/LOCK_TABLES.html

 

[fixxxer]

Если вы используете таблицы, не поддерживающие транзакций,

то вы идиот!

Но вообще в случае с isFree/book можно обойтись и без транзакций - добавить в update-запрос условие на is free и проверять affected rows.

 

[Redjik]

Обычно нет необходимости блокировать таблицы, поскольку все единичные команды UPDATE являются неделимыми; никакой другой поток не может взаимодействовать с какой-либо SQL-командой, выполняемой в данное время.

Я жене iphone купил на деньги вырученные с продаже китайского хлама.
Откуда китайский хлам? Дак у китайских ребят, которые билинг делали на одном китайсайте были такие же заблуждения

5 one plus one == ihpone6(128)

 

[MiksIr]

Но вообще в случае с isFree/book можно обойтись и без транзакций - добавить в update-запрос условие на is free и проверять affected rows.

Говори уж профессиональным языком - оптимистичная блокировка

 

[WMix]

Блажен кто верует