- Регистрация
- 04.04.2015
- Сообщения
- 1 763
- Благодарностей
- 1 391
- Баллы
- 113
Приветствую.
При работе с БД в зенке столкнулся с очень неприятной вещью, а именно периодической сменой CONNECTION ID в рамках потока ...
Итак, допустим шаблон состоит из нескольких кубиков для работы с БД, между ними есть какая-то логика (сейчас не важно какая). Допустим первый кубик создает соединение с БД с идентификатором 1111, второй и последующие кубики уже могут подхватить не это соединение, а соединение от первого кубика из вообще другого потока зенки!
Что это означает на практике?
Допустим у нас есть такая логика:
1) лочим таблицы
2) делаем запрос на получение каких-то данных
3) как-то, допустим, работаем с полученными из бд данными
4) записываем/обновляем данные в бд
5) разлочиваем таблицы
В одном кубике все эти операции не выполнить, соответственно задача разбивается на несколько кубиков ... В результате при попытке разлочить таблицу мы уже можем иметь совершенно другой connection id, а не тот при котором лочили (!) ... соответственно unlock не сработает
Или другая ситуация: один поток залочил таблицы и делает долгий и тяжелый запрос, а паралелльный поток зенки подхватил соединение первого и в результате вообще не имеет доступа к каким-либо таблицам так как: Пока клиент удерживает явную блокировку, он не может использовать другие таблицы, поэтому блокировать нужно сразу все что понадобится (одним выражением), так как повторное использование оператора LOCK TABLES отменяет сделанные ранее блокировки.
Вот для примера небольшой шаблон, который генерит случайную строку (идентификатор потока в ZP) и просто с некоторой задержкой делает запрос к БД получая CONNECTION _ID ...
Запускаем его допустим в 2 потока и смотрим лог:
Тут мы видим что поток с идентификатором 69GJD при первом вызове кубика работы с БД имел CONNECTION ID = 2270, а следющие 2 кубика работы с БД (в этом же потоке 69GJD) уже использовали CONNECTION ID полученный в другом потоке зеннопостера (2269)... с другим потоком все то же самое
Отсюда вопрос: можно ли как-то заставить в рамках потока ZP использовать одно и то же соединение (до таймаута), а не подхватывать соединения созданные другими потоками ???
p.s у меня зенка старая 5.11.4, может в новых версиях как-то по другому?
При работе с БД в зенке столкнулся с очень неприятной вещью, а именно периодической сменой CONNECTION ID в рамках потока ...
Итак, допустим шаблон состоит из нескольких кубиков для работы с БД, между ними есть какая-то логика (сейчас не важно какая). Допустим первый кубик создает соединение с БД с идентификатором 1111, второй и последующие кубики уже могут подхватить не это соединение, а соединение от первого кубика из вообще другого потока зенки!
Что это означает на практике?
Допустим у нас есть такая логика:
1) лочим таблицы
2) делаем запрос на получение каких-то данных
3) как-то, допустим, работаем с полученными из бд данными
4) записываем/обновляем данные в бд
5) разлочиваем таблицы
В одном кубике все эти операции не выполнить, соответственно задача разбивается на несколько кубиков ... В результате при попытке разлочить таблицу мы уже можем иметь совершенно другой connection id, а не тот при котором лочили (!) ... соответственно unlock не сработает
Или другая ситуация: один поток залочил таблицы и делает долгий и тяжелый запрос, а паралелльный поток зенки подхватил соединение первого и в результате вообще не имеет доступа к каким-либо таблицам так как: Пока клиент удерживает явную блокировку, он не может использовать другие таблицы, поэтому блокировать нужно сразу все что понадобится (одним выражением), так как повторное использование оператора LOCK TABLES отменяет сделанные ранее блокировки.
Вот для примера небольшой шаблон, который генерит случайную строку (идентификатор потока в ZP) и просто с некоторой задержкой делает запрос к БД получая CONNECTION _ID ...
Запускаем его допустим в 2 потока и смотрим лог:
Тут мы видим что поток с идентификатором 69GJD при первом вызове кубика работы с БД имел CONNECTION ID = 2270, а следющие 2 кубика работы с БД (в этом же потоке 69GJD) уже использовали CONNECTION ID полученный в другом потоке зеннопостера (2269)... с другим потоком все то же самое
Отсюда вопрос: можно ли как-то заставить в рамках потока ZP использовать одно и то же соединение (до таймаута), а не подхватывать соединения созданные другими потоками ???
p.s у меня зенка старая 5.11.4, может в новых версиях как-то по другому?
Последнее редактирование: