Одновременное множественное обращение к строке- помогите решить (MySql4.1)

[shadx]

Сообщение от Йода

Вот сматри:
есть два обработчика О1 и О2. Оба нашли свободную строчку- и ломятся ее сначала зарезервировать (тоесть как раз UPDATE SET столбец=айди WHERE столбец=0 ) а потом сделать контрольный Селект, так?
Может получится, что О1 и О2 делают апдейт. Естессно- ктото успевает первым (пусть О1). Второй апдейт ждет. О1 сделал апдейт и делает селект (селект не ждет) - считывает свое только что установленное значение и свято верит что строчка им залочена. После этого доходит очередь до апдейта О2 и последующего егоже селекта. В результате оба верят что строчка залочена именно им.

Тут играет роль приоритетность селекта и апдейта. В принципе это в mysql настраивается, но все равно выглядит это както хлипко..

Добавлено через 1 минуту

угу.. ну это естессн..

Легко хлипкость устраняется.
Если поставить условие, что в один момент времени один обработчик может захавать одну строчку.

Тогда обработчик, на очередном этапе цикла, делает

UPDATE SET столбец=айди WHERE столбец=0 LIMIT 1

И забирает себе одну строку.
После обработки он айди снимает.

Даже если их будет сотня они не подерутся.

[Alexey]

shadx, уху. И я про то же еще несколькими постами выше написал.

UPDATE конфликтовать не будут даже если их тысяча придет ровно в один момент. А селект уже не важно будет идти сразу или не сразу после апдейта, ибо строчка уже зарезервирована и ее никто не тронет.

В общем, советую сделать эскизный проект:
1) берется база данных, в ней такой столбец.
2) Забивается миллионом любых строк
3) В программе создается 100 потоков и они одновременно резервируют себе по строке.
4) Смотрите что получилось.

Быстренько накидать такую прогу - примерно 10-20 минут надо. Зато сразу все вопросы отпадут. И нам расскажете, как оно

Эскизные проекты рулят: времени тратится меньше часа, позволяет оценить точно и четко масштаб проблемы и потом времени и нервов экономится просто несказанно много. И исполнителю хорошо: зная заранее о том, сколько потребуется сил на реализацию чего-то можно грамотней распланировать свой график. И заказчик всегда доволен: все любят, когда прогнозы по срокам сбываются.

[Последний Герой]

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

В программе создается 100 потоков и они одновременно резервируют себе по строке.

у вас есть 100 процессоров? иначе не будет одновременного выполнения как бы вы не старались. проще перетасовать запросы от "разных" потоков и пустить одним.

[EndyVelvet]

Сообщение от Последний Герой

у вас есть 100 процессоров? иначе не будет одновременного выполнения как бы вы не старались. проще перетасовать запросы от "разных" потоков и пустить одним.

Давным давно я был игровым программистом, в настоящее время многопотоком (threading) подгружается куча текстур и моделей + выполняется куча операция для удаления загрузки уровней.
Такое не сложно реализовать и на Delphi, или Вы хотите сказать у Вас операционная система все по очереди делает?

http://yandex.ru/yandsearch?text=ass...fx3&clid=46510

[Йода]

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

Йода, хорошо, развиваем мысль.

Значит задача - сделать децентрализованную систему. И, желательно, простую (да, люблю я простоту. Считаю что все гениальное - просто).

Делаем MEMORY таблицу с одним единственным AUTO_INCREMENT полем (хранится в памяти, на 1 запись тратится длина, равная sizeof(int), выборки и вставки ультра быстрые).

Обработчик при своем запуске делает в нее INSERT, и забирает свой идентификатор через LAST_INSERT_ID(). Таким образом, мы получаем уникальные непересекающиеся числовые идентификаторы для каждого процесса, которые не будут сохраняться на диск.

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

Ага. Спасибо. Мысль ясна и изящна. Вкурю её.

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

Легко хлипкость устраняется.
Если поставить условие, что в один момент времени один обработчик может захавать одну строчку.

Тогда обработчик, на очередном этапе цикла, делает

UPDATE SET столбец=айди WHERE столбец=0 LIMIT 1

И забирает себе одну строку.
После обработки он айди снимает.

Даже если их будет сотня они не подерутся.

shadx, ага. Слушай, я до этого думал так- сначала обработчик находит удоволетворяющую его строку (селект со сложным условием) и узнает id этой строки, а уже потом делает ей выстановку флага занятости. А если сразу делать выстановку по этому самому сложному условию то естессно, у нас останутся только апдейты и они меж собой всяко не законфликтуют.
Вопрос тут один- а как обработчик узнает id той строки, на которую он только что выставил флаг? Наверное это просто- но я туплю. Если это так- тоесть если есть возможность узнавать id строчки на которую выпал выбор субд при выполнении апдейта с учетом того что в секции where не стоит этого самого id строки- то получается, что это самый простой способ. Это и децентрализованно, и нет проблемы отслеживания смерти обработчиков, регистрации обработчиков в диспетчере и самого диспетчера

Сообщение от Последний Герой

у вас есть 100 процессоров? иначе не будет одновременного выполнения как бы вы не старались. проще перетасовать запросы от "разных" потоков и пустить одним.

Не уверен на все сто, но кажецца ты не прав. При таком программировании (мы же не на низком уровне под реалтайм ОС пишем) можно считать что программы выполняются параллельно и одновременно. Но как я писал- не уверен. Но вроде бы также мыслит и CAESARARTS.

[boric]

Йода

Вопрос тут один- а как обработчик узнает id той строки, на которую он только что выставил флаг? Наверное это просто- но я туплю.

Ставьте апдейтом блокировку сразу на несколько записей:
UPDATE SET столбец=айди WHERE столбец=0 LIMIT 10

Потом селектом считывайте все, что заблокировалось этим обработчиком:
SELECT * FROM ... WHERE столбец=айди
и далее обработчик пусть обрабатывает эти строки.

[Последний Герой]

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

у Вас операционная система все по очереди делает

время на ЦП делится не по каждой простой процессорной команде, а по блокам команд, отсюда вывод такой. в любом случае демон mysql работает 1 потоком на исполнение запросов.

Сообщение от Йода

Не уверен на все сто, но кажецца ты не прав. При таком программировании (мы же не на низком уровне под реалтайм ОС пишем) можно считать что программы выполняются параллельно и одновременно. Но как я писал- не уверен. Но вроде бы также мыслит и CAESARARTS.

я немного наврал про 100 процессоров. 1 демон mysql, 1 поток на исполнение запросов SQL, а вот попасть они могут в него в любом порядке, поэтому вариант с перетасовкой слияния подойдет

[Alexey]

Вопрос тут один- а как обработчик узнает id той строки, на которую он только что выставил флаг?

А очень просто - скрипт может выбрать все необработанные строки, принадлежащие его идентификатору

[shadx]

Вообсчем, тут пробовать надо Но в любом случае ничего особо сложного нету ...

[Atomic]

Смотрите реализацию репликации в мускуле (исп множества серверов для обработки одних и тех же данных).