Delphi ADO асинхронно

← →
Псалтырь (2007-06-24 12:51) [0]

В чем прелесть этой связки? Только лишь в том, что можно отображать прогресс? Ведь до момента OnFetchComplete я не смогу ничего сделать с датасетом (показать, редактировать, удалить)?

Ткните носом по этой теме куда-нибудь, будьте добры. А то я ее не понимаю и боюсь. :)

Спасибо

← →
Anatoly Podgoretsky © (2007-06-24 13:20) [1]

> Псалтырь (24.06.2007 12:51:00) [0]

Зато можешь делать все другое.

← →
Псалтырь (2007-06-27 22:24) [2]

Мне бы деталей. Я так и не нашел примеров или объяснений... Как оно все задумано-то?

← →
Сергей М. © (2007-06-28 09:34) [3]

> Как оно все задумано-то?
>

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

← →
Псалтырь (2007-07-01 15:04) [4]

Ну оно-то да...

Вот сделали мы комманду Open, датасет начал свою работу. А я до наступления OnFetchComplete имею право вызывать методы датасета? Например, First, Next, в смысле навигационные. Имеют ли они смысл? Грид будет заполняться по мере получения данных или он станет доступным только после окончания процесса? Могу ли я делать Insert, Modify & Delete? Что из себя представляет датасет от начала открытия до OnFetchComplete ? Или я могу заниматься только своими делами попутно уведомляя юзера о прогрессе?

Извините, если скомкано.

← →
sniknik © (2007-07-01 15:25) [5]

> имею право вызывать методы датасета?
попробуй и узнаешь...

← →
Псалтырь (2007-07-01 19:15) [6]

> sniknik © (01.07.07 15:25) [5]

А можно просто ответить? Я же не куски кода выпрашиваю.

У меня Акссес только, смогу я на нем эмулировать нужное поведение для тестов?

← →
sniknik © (2007-07-01 19:58) [7]

> А можно просто ответить?
можно. но проверить гораздо быстрее... тем более тому кто будет отвечать тоже нужно проверить, и гораздо больше т.к. не он не знает конкретных условий. (вернее теперь знает > "У меня Акссес")

> У меня Акссес только, смогу я на нем эмулировать нужное поведение для тестов?
ну а почему нет? так ты узнаешь поведение методов для access (jet)... но это не гарантирует, что oracle например, не выдаст, "не поддерживается в данном режиме".

← →
Псалтырь (2007-07-01 20:25) [8]

> sniknik © (01.07.07 19:58) [7]

> но это не гарантирует, что oracle например, не выдаст, "не
> поддерживается в данном режиме".

То есть единого стандарта нет, и каждый драйвер вправе решать по-своему? Я не тупой, просто абсолютно не знаком с темой. А клиенты просят реализовать в самописном датасете асинхронность. А я даже пощупать не могу ибо не знаю с чего начать.

← →
sniknik © (2007-07-01 20:48) [9]

> в самописном датасете
??? нафига? (я еще понимаю для серверного курсора, что не реализовано (и для чего асинхронный фетч безсмысленнен)... ну а так. нафига? )

> А я даже пощупать не могу ибо не знаю с чего начать.
ну начни с изучения ADODataSet-а, они то както реализовали... и на самом деле неважно что ответит провайдер, главное правильная реакция на действие и исключение на отказ.

← →
Псалтырь (2007-07-01 21:05) [10]

> sniknik © (01.07.07 20:48) [9]

> нафига? )

Я думаю "шоб було".

> ну начни с изучения ADODataSet-а, они то както реализовали.
> ..

Дык это всего лишь обертка. Вся "механика" спрятана.

← →
sniknik © (2007-07-01 21:20) [11]

> Дык это всего лишь обертка. Вся "механика" спрятана.
ну так ты заявил что у тебя ADO... т.е. датасет ты на нем "наворачиваешь" (чего и удивляюсь. нафига?)

а если не на нем, то какая тебе разница как сделано? сделай так как считаеш нужным, лучшим.

← →
Псалтырь (2007-07-02 10:03) [12]

> sniknik © (01.07.07 21:20) [11]

> ну так ты заявил что у тебя ADO... т.е. датасет ты на нем
> "наворачиваешь"

Мы друг друга не поняли. :) Датасет не имеет ничего общего с АДО. Он наследник TDataset и ближе по структуре к TBDEDataset, чем к TADODataset. Однако клиенту хочется асинхронности. По большому счету, мне нужно узнать только одно: что есть в асинхронности такого, чтобы извиваться и внедрять ее в код. Потому и вопрос таким образом стоит. Мне главное - это аргументы в разговоре.

Выглядело это все примерно так:
Клиент: А сделайте асинхронность.
Я: А где это уже реализовано?
Клиент: АДО

Дальше я не интересовался, дабы не прослыть ламером :)

← →
Anatoly Podgoretsky © (2007-07-02 10:11) [13]

C каждым новым сообщения все более неожиданных вещей проявляется.
Акцесс отлично работает с АДО, это родной для него протокол.

← →
sniknik © (2007-07-02 10:57) [14]

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

и потому если клиент хочет асинхронности (для чегото она ему нужна, пусть хотябы только количество принятых записей считать) то делай (выясни что нужно, чтобы не делать лишнего), либо предложи пользоваться ADO.

← →
Псалтырь (2007-07-02 22:27) [15]

> sniknik © (02.07.07 10:57) [14]

Спасибо за содержательную беседу

← →
MsGuns © (2007-07-03 00:14) [16]

Асинхронное соединение очень полезно в случаях, когда с клиента посылаются серверу запросы на выполнение длительных по времени расчетов или выборок (чаще всего ХП), а клиентское приложение должно быть "реактивно" для того, чтобы пользователь мог как просматривать результаты уже завершенных выборок, так и запускать новые.

← →
MsGuns © (2007-07-03 00:15) [17]

Асинхронность часто используется совместно с многопоточноостью

← →
sniknik © (2007-07-03 00:55) [18]

> Асинхронность часто используется совместно с многопоточноостью
и совершенно зря, ибо бессмысленно. асинхронность это само по себе многопоточность, только реализованная в компоненте(/обьекте ADO), "наружу" выдаются события о состоянии этого внутреннего потока/его данные. зачем это все еще в собственные потоки пихать не представляю, разве что, чтобы помучиться с обработкой событий потока... (программистский мазохизм...?)

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

← →
MsGuns © (2007-07-03 11:48) [19]

>sniknik © (03.07.07 00:55) [18]
> Асинхронность часто используется совместно с многопоточноостью
и совершенно зря, ибо бессмысленно.

Смысл, однако, есть.
В случаях, когда реализуется многооконный (MDIForm) интерфейс, позволяющий одновременно запускать однотипные запросы и просматривать "параллельно" полученные результаты в нескольких экземплярах формы одного класса. В этом случае схема "одна форма - один поток - один асинхронный запрос"

← →
ЮЮ © (2007-07-03 11:52) [20]

> В этом случае схема "одна форма - один поток - один асинхронный
> запрос"

А чем хуже схема "одна форма - один асинхронный запрос"?

← →
sniknik © (2007-07-03 11:55) [21]

> В этом случае схема "одна форма - один поток - один асинхронный запрос"
"один поток" в этой схеме лишний. думаю уже обьяснил почему.

← →
sniknik © (2007-07-03 11:57) [22]

> А чем хуже схема "одна форма - один асинхронный запрос"?
лучше. тем более это позволит оставить один коннект а не плодить их на каждый поток (для локального FB например, это оч.важно).

← →
MsGuns © (2007-07-03 12:04) [23]

Поток, "завернутый" в форму (или кудато там еще) позволяет своевременно сообщать гл.форме о выполнении того или иного этапа алгоритма,- например, для перерисовки некоего "табло активных процессов", что достаточно удобно для пользователя. А также дает возможность прервать выполнение некоторого задания (потока) в любой момент.

← →
sniknik © (2007-07-03 12:17) [24]

> Поток, "завернутый" в форму (или кудато там еще) позволяет своевременно сообщать гл.форме ...
зачем нужны потоки, и что удобно пользователю можеш не объяснять, объясни лучше зачем нужен посредник, промежуточный поток между формой и потоком асинхронного вызова?
вот вопрос.
ведь единственное чего в этом случае добиваешься так это того что события потока от вызова придут в твой дополнительный поток, которые он просто перенаправит основному (форме. а куда еще если это событие о завершении считывания, например, и надо отобразить данные на форме, или счетчик принятого количества записей, тоже вывод на форму... и т.д.).

> А также дает возможность прервать выполнение некоторого задания (потока) в любой момент.
асинхронный вызов обладает теми же свойствами. (неудивительно, это же тоже поток...)
и?

← →
Anatoly Podgoretsky © (2007-07-03 12:33) [25]

> ЮЮ © (03.07.07 11:52) [20]
> А чем хуже схема "одна форма - один асинхронный запрос"?

Тем что потоков в два раза меньше

← →
Anatoly Podgoretsky © (2007-07-03 12:34) [26]

sniknik © (03.07.07 11:57) [22]
Если коннект один, то запросы будут выполняться последовательно, а не паралельно. Особенность АДО

Anatoly Podgoretsky © (03.07.07 12:34) [26]
откуда дровишки?
если уж на то пошло то выполняет запрос не адо, а sql сервер, если он для одного коннекта выделяет/использует только один поток... ну так это не проблема адо.

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

Не помню точно откуда, но это из многих источников.
Проблема именно АДО, а не сервера, сервер в состоянии обрабатывать многие тысячи запросов паралельно.
Если одно соединение, то все запросы выстраиваются в очередь.
Ну и к тому же я не про фетч, а про запросы. Фетч вполне возможно и вероятнее всего идет паралельно (точнее переключение между порциями получаемых с сервера). Это уже транспортный уровень.

> Проблема именно АДО
если это так, то это очень странно, надо проверить.

ну не знаю, возможно это и было так когдато (множество источников не могут ошибаться, как и миллионы мух ;о))), но сейчас не подтверждается

простая проверка (MSSQL)
сделал таблицу
CREATE TABLE TstVal (ID INT Identity(1, 1), Name VarChar(30), Row Int, Dat DateTime DEFAULT GetDate())

на форму положил коннект, и 2 подключенных к нему комманда, поставил опции в обоих [eoAsyncExecute] (именно асинхронное выполнение)
в первом запрос (пакет)
SELECT * FROM Tst
INSERT INTO TstVal (Name,Row) VALUES ("First", @@ROWCOUNT)

во втором
INSERT INTO TstVal (Name,Row) VALUES ("Second", 0)

выполняем по кнопке
procedure TForm1.Button1Click(Sender: TObject);
begin
ADOConnection1.Open;

ADOCommand1.Execute;
ADOCommand2.Execute;

Button1.Enabled:= false;
end;

после выполнение в таблице видим
ID, Name, Row, Dat
1, Second, 0, 03.07.2007 15:18:37
2, First, 71464, 03.07.2007 15:18:39

т.е. второй запрос выполнился раньше. где очередь?... если бы она была, то записи положились бы строго последовательно, как их вызвали на выполнение.

более наглядно. поменял запросы на
первый
INSERT INTO TstVal (Name,Row) VALUES ("First", 0)
SELECT * FROM Tst
INSERT INTO TstVal (Name,Row) VALUES ("Second", @@ROWCOUNT)

второй
INSERT INTO TstVal (Name,Row) VALUES ("Third", 0)

после выполнения последовательность
ID, Name, Row, Dat
3, First, 0, 03.07.2007 15:35:39
4, Third, 0, 03.07.2007 15:35:39
5, Second, 71464, 03.07.2007 15:35:47

видим что второй запрос выполнился в середине первого, т.е. явно с другого потока.

Ты уверен, что запрос Second "достучался" до сервера первым ?

см. [31] это развеет твои сомнения...
кстати еще пробовал и во второй запрос вставить селект к другой таблице (чтобы не было блокировок), небольшой с гарантией выполняющийся раньше первого (чтобы время записи второго запроса было примерно на половине чтения первого) и ничего, все нормально.
это на случай если кому голову придет что пакет это не запрос и "очередь" надо считать не по нему, а по запросам внутри его.

p.s. мухи всетаки ошибаются.

← →
Псалтырь (2007-07-03 21:55) [34]

А как такая ситуация выглядела бы для возвращаемых данных, то есть SELECT?

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

Примерно так

запрос 1 поток 1
запрос 2 поток 2
запрос 3 поток 3
запрос 4 поток 4

Запросы передаются на сервер по мере поступления, пока один запрос не передан остальные не передаются. Если это так, то для изучения надо создавать очень много запросов достаточного большого размера, да еще подумать как это организовать, что бы была ясность.

Я просто воспринял эту информацию и когда делал много поточное приложение учел это и делал по отдельному AdoConnection на каждый поток.

> по отдельному AdoConnection на каждый поток.
для собственных потоков это как раз нормально, но у нас то разговор про асинхронные вызовы где потоки само ADO организовывает. и вот в этом случае при выполнении запросов в собственных потоках, сами асинхронные вызовы будут лишними (уже в дополнительном, зачем еще тратится событийность организовывать для асинхронных если легко с синхронными сделать все линейно)

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

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

Delphi ADO асинхронно Найти похожие ветки