Не пойму сути компонентов а-ля TTransaction

← →
sniknik © (2009-06-13 15:51) [120]

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

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

> Где-то есть, наверное, решение, но пока вот не нашел..
асинхрон команде, а для ее остановки "глушить" коннект (active:= false).
должно получиться... и если получится смотри действия которые выполняются, для команды при закрытии коннекта в генофонде.

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

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

в общем у ADO есть своя идеалогия (как и у транзакций в сабже и всего другого), и ее нужно соблюдать, или будут глюки.

← →
Холивар (2009-06-13 18:28) [121]

> PEAKTOP © (13.06.09 10:54) [115]
>
> > Только и в литературе по FireBird и в документации очень
> не рекомендуется так делать
>
> Вы внимательно этот абзац прочитайте. Полностью прочитайте,
> особенно тот момент, где описывается в каких имеено случаях.
>
>
> <OFFTOP>
> У нас в Украине уголовный кодекс наносить гражданам тяжкие
> телесные повреждения тоже не рекомендует делать. А в случаях
> необходимой самообороны при нападении - разрешает. А из
> жизненного опыт Вам скажу, что это не только можно делать,
> но и нужно делать.
> =)
> </OFFTOP>

Я почему-то предпочитаю не доводить ситуацию до "нанесения тяжких телесных повреждений". Это гораздо проще, чем доказывать потом что именно ты прав.

Поэтому правило 1 поток - 1 коннект хорошо для любых ситуаций.

>sniknik © (13.06.09 15:51) [120]
>но вообще, при асинхронной работе с ADO не нужны свои потоки, т.е. >асинхронность это и есть выполнение команд в доп. потоках, только >созданных не вами, а самим ADO. если делаются свои, то их работа и >внутренних ADO должна согласовываться. (что несколько проблематично, >т.к. такой схемы не предусмотрено, а код объектов ADO закрыт)

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

>в общем у ADO есть своя идеалогия (как и у транзакций в сабже и всего >другого), и ее нужно соблюдать, или будут глюки.

Глюки можно преодолевать, но много надо морщиться. О чем я и писал, собственно

Не пойму сути компонентов а-ля TTransaction Найти похожие ветки