Поведение ADOConnection в многопоточном приложении

← →
Ega23 © (2005-11-09 12:11) [40]

> Если основной коннект будет делать запросы из той же таблицы,
> которая апдейтится другим коннектом, то MS SQL сам тебя
> тормознет на время выполнения транзакции обновления (т.е.
> селект не выполнится пока апдейт не закончится

Низачот. Это всё регламентируется Isolation Level"ом. Я могу и "грязное чтение" делать (собственно, я его и делаю). For Browse которое.

← →
ANB © (2005-11-09 12:21) [41]

Таки выходит, что отдельные потоки на одном коннекте все равно ничего не дадут. Т.к. фактически именно коннект будет все делать, а остальным потокам, которые встали позже, придется ждать тапок. А расчет времени для последовательных апдейтов делали ? Если ты сможешь убрать блокировку на одновременный апдейт одной таблицы, то для параллельности придется для каждого потока заводить свой коннект. А потоки придется делать для каждого датчика. Это некузяво, ИМХО.

← →
Ega23 © (2005-11-09 12:25) [42]

> Таки выходит, что отдельные потоки на одном коннекте все
> равно ничего не дадут. Т.к. фактически именно коннект будет
> все делать, а остальным потокам, которые встали позже, придется
> ждать тапок. А расчет времени для последовательных апдейтов
> делали ? Если ты сможешь убрать блокировку на одновременный
> апдейт одной таблицы, то для параллельности придется для
> каждого потока заводить свой коннект. А потоки придется
> делать для каждого датчика. Это некузяво, ИМХО.

Ты, по-моему, куда-то не туда полез.
В принцине, sniknik © в [34] и [35] посоветовал достаточно красивое решение проблемы. Сейчас будем пробовать.

← →
root © (2005-11-09 13:57) [43]

если одна база ито RemoteDataModul там все это реализованно

ядумаю отсюдаплесать надо

← →
Ega23 © (2005-11-09 15:36) [44]

В общем так.
По совету sniknik © сделали запрос параметризованным и перешли там, где критично с ADOQuery на ADOCommand и ADODataSet.
Результаты ошеломляющие - такт системы сократился с 300 мс до 1,5 мс. Т.е. в 200 РАЗ!!!

sniknik ©, с меня при встречи много пива! ОГРОМНОЕ СПАСИБО!

← →
WondeRu © (2005-11-09 16:57) [45]

Ega23 © (08.11.05 17:28) [2]
у дополнительного потока всё-таки СВОЙ коннект, или нет?
свой!

← →
Slym © (2005-11-10 13:51) [46]

Если не требуется возвращать результат запроса то решение: 1! поток с очередью.
В очередь ставишь строку SQL и массив параметров.
или более предпочтительный вариант: поток знает все запросы (для каждого свой компонент создан) и только параметры подставляй.

в потоке выбираешь очередь и постишь в базу.

Ega23 © (09.11.05 15:36) [44]
сократился с 300 мс до 1,5 мс.
если строка SQL не меняется ты ей еще Prepare сделай

← →
Ega23 © (2005-11-10 16:05) [47]

> если строка SQL не меняется ты ей еще Prepare сделай

меняется.

← →
ANB © (2005-11-10 17:47) [48]

> Ega23 © (10.11.05 16:05) [47]

А набор запросов на апдейт фиксированный ?

← →
Ega23 © (2005-11-11 10:49) [49]

> А набор запросов на апдейт фиксированный ?
>

Не понял.

> В смысле - количество вариантов запроса - конечное число
> ?

В данный момент - да, но система в любой момент может расшириться.

> Ega23 © (11.11.05 17:17) [51]

Я к тому, что можно завести массив кверей (по одной на каждый вариант апдейта) и каждую пропрепарить. Хотя я наступал на грабли с препаре, но это было оракл + одак. Плюс я его зря делал.

> Я к тому, что можно завести массив кверей (по одной на каждый
> вариант апдейта) и каждую пропрепарить. Хотя я наступал
> на грабли с препаре, но это было оракл + одак. Плюс я его
> зря делал.
>

Да уже всё и так нормально.

Поведение ADOConnection в многопоточном приложении Найти похожие ветки