DBExpress async call

← →
_vvv_ (2005-09-26 12:02) [0]

Привет народ!

Кто-нибудь пробовал работать с Oracle через DBExpress используя асинхронный вызов запросов. В драйвере есть соответствующая опция.
В общем случае задача стоит такая:
Организовать параллельный вызов нескольких запросов через одно соединение.
У кого есть опыт, плиз, поделитесь.

Спасибо

← →
Desdechado © (2005-09-26 13:04) [1]

разве "асихронный"=="параллельный"?

← →
evvcom © (2005-09-26 13:42) [2]

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

← →
_vvv_ (2005-09-26 13:51) [3]

> разве "асихронный"=="параллельный"?

Я предполагал, что можно запустить два асинхронных запроса и проверять их состояние.

← →
_vvv_ (2005-09-26 13:53) [4]

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

Имеется запрос с фильтрацией на большую таблицу.
Первые записи фетчатся быстро, но надо еще и посчитать Count.
Много индексов тоже не могу положить.

← →
Sergey13 © (2005-09-26 14:15) [5]

2[4] _vvv_ (26.09.05 13:53)
> Первые записи фетчатся быстро, но надо еще и посчитать Count.
Посчитай отдельным запросом (или приделай к основноve через union). Фетч от ассинхронности по любому не ускорится. Может вообще ну его на фиг запрос возвращающий на клиента столько записей.

← →
evvcom © (2005-09-26 14:18) [6]

> Первые записи фетчатся быстро

А при чем здесь fetch? Запрос открывается, делается fetch 25 записей (в ОДАКе это так), тут же можешь открывать второй запрос и фетчить его 25 записей. Потом вернуться опять к первому и фетчить его дальше. В чем проблема-то?

← →
_vvv_ (2005-09-26 14:38) [7]

> А при чем здесь fetch? Запрос открывается, делается fetch
> 25 записей (в ОДАКе это так), тут же можешь открывать второй
> запрос и фетчить его 25 записей. Потом вернуться опять к
> первому и фетчить его дальше. В чем проблема-то?

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

← →
_vvv_ (2005-09-26 14:42) [8]

> > Первые записи фетчатся быстро, но надо еще и посчитать
> Count.
> Посчитай отдельным запросом (или приделай к основноve через
> union). Фетч от ассинхронности по любому не ускорится. Может
> вообще ну его на фиг запрос возвращающий на клиента столько
> записей.

Я согласен, но не заказчик.

← →
Sergey13 © (2005-09-26 14:47) [9]

2[8] _vvv_ (26.09.05 14:42)
А что заказчик? Заказал конкретно не менее 100000 записей читать? И всю инфу за 5 лет в гриде смотреть? 8-)

← →
_vvv_ (2005-09-26 15:10) [10]

> А что заказчик? Заказал конкретно не менее 100000 записей
> читать? И всю инфу за 5 лет в гриде смотреть? 8-)

Я фетчу только первую тысячу, далее он может подчитывать следующую партию.
Но общую статистику по таблице я должен показать.

2[10] _vvv_ (26.09.05 15:10)
Не делай ничего. Если будет ругаться на "медленно" скажи ему, что он сам так хотел.
"Больших семь шапок из овцы не выкроишь никак."
(С) Классик детской литературы.

← →
_vvv_ (2005-09-26 16:11) [12]

Мы отвлеклись от основной темы.
Неужели никто не пробовал асинхронно работать с DBExpress?

Работал, но асинхронный метод не использовал ..... ИИИ

> В общем случае задача стоит такая:
> Организовать параллельный вызов нескольких запросов через
> одно соединение.

Насколько Я понял Вам Дали Ясно понять что подобное невозможно :-\

1. Перейти на прямой доступ (ODAC, DOA)
2. Завести пулл сессий.

> Count отрабатывает долго

А может ты просто запрос неоптимально написал? Я на днях первое, что написал был обычный select с join-ами нескольких таблиц (на выходе тыс.50-70 записей), потом join с таблицей через dblink (около 200 тыс.записей) и еще один локальный join. Запрос отрабатывал 1,5 минуты в задаче, где пользователь должен был вводить данные. Он бы повесился, тратив по 1,5 минуты на ожидание при вводе каждого документа. Целый день я потратил на оптимизацию сего запроса. В результате вышел на результат менее 1 секунды.
А у тебя, если все данные на одном сервере, так это вообще просто.

DBExpress async call Найти похожие ветки