SELECT и UPDATE одновременно в многопотоке

[zortexx]

1. LOCK TABLES links WRITE;
   SELECT url FROM links WHERE post = '0' AND keywords = '{-Variable.key-}';
   UPDATE links SET post='1' WHERE keywords = '{-Variable.key-}';
   UNLOCK TABLES;
   
   Локается вся таблица?
   или только строки, с которыми связан запрос?

А из кода разве непонятно?
https://dev.mysql.com/doc/refman/5.7/en/lock-tables.html

 

[WebBot]

Как альтернатива локам в самом MySQL, можно всю работу с БД перенести в кубик C# и просто лочить его ... никакой другой поток не вклинится в работу с БД

lock(SyncObject){
// тут работаем с БД
}

 

[one]

Локается вся таблица?

Таблица.

потоки отваливаются не успев дождаться пока лок снимется.

Вообщем у меня получается что бы не сыпались ошибки по таймаут разлока таблица нормально шаблон может работать в 25 потоков. Если больше, начинаются потоки отваливается по ошибке. Судя по всему, особенности метода лока.

 

[one]

Как альтернатива локам в самом MySQL, можно всю работу с БД перенести в кубик C# и просто лочить его ... никакой другой поток не вклинится в работу с БД

lock(SyncObject){
// тут работаем с БД
}

Конвертировать в С#? Он по моему с ошибкой конвертиться. Не знаю, может пофиксили. Можете выложить рабочий пример запроса?

 

[one]

Локается вся таблица?
или только строки, с которыми связан запрос?

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

 

[WebBot]

Конвертировать в С#? Он по моему с ошибкой конвертиться. Не знаю, может пофиксили. Можете выложить рабочий пример запроса?

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

 

[WebBot]

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

Это должен поддерживать движок ... например таблицы MyISAM в принципе не имеют поддержки локов на уровне строк, а InnoDB имеет. Но у вас все равно 2 отдельных запроса и между ними кто то может вклиниться

 

[inotoxic]

Вообщем у меня получается что бы не сыпались ошибки по таймаут разлока таблица нормально шаблон может работать в 25 потоков. Если больше, начинаются потоки отваливается по ошибке. Судя по всему, особенности метода лока.

Может ограничение на кол-во потоков стоит на уровне БД ?
Проверить можно запросом

show variables like 'max_connections';

Стандартное ограничение 30 потокв

 

[one]

У меня выставленно с запасом.

max_connections = 550

 

[WebBot]

Камрады, у кого свежая версия ZP ? Там поправили код C# получаемый из кубика для работы с MySQL ?
А то сейчас срочно понадобилось заюзать БД, а в моей 5.11.4 код при конвертации в C# получается не рабочий.
Буду премного благодарен если кинете рабочую версию кода с помещением результата в список ... ну и для запросов без ответа и скаляра то же не помешал бы, там видимо код немного различается.