| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
потокобезопасность класса TADOConnection [D7, Win2k, WinXP]
Arm79 © (2006-10-30 16:29:00)Уважаемые мастера
Насколько мне известно АДО само по себе потокобезопасно.
А вот насколько потокобезопасны стандартные компоненты для работы с АДО? Особенно интересует ADOConnection
Спасибо.
Сейчас идет этап проектирования, не хотелось бы ошибаться в самом начале.
sniknik (2006-10-30 20:15:00) [1]> используя отдельный экземпляр ADOConnection в каждом потоке я бы не был на 100% уверен что
> будет стабильная работа. Не знаю как с ADO
83-87 (~) потока содержащих по коннекту и т.д. это наш "рекорд" ;о)), но это правда стресс тестирование не проходило... только в рабочем режиме проверялось (ну не ожидали, что клиент столько устройств нацепит, ожидалось это решение под 10 ну максимум 20 устройств, поэтому проверялось на 30ти...), устройства данные получают из mssql, и каждое полностью автономное поэтому решение - вся обработка одного, в отдельном потоке очевидна. (устройства еще и медленные (весы), т.что параллельная загрузка очень кстати, получается все, неважно сколько их, по времени загружаются примерно столько же сколько одни... (вернее полторы/двое последовательно;))
на стабильность не жаловались. тфу, тфу чтоб не сглазить :о))
да, решение/программа не моя, хотя как консультант по ADO я там немного участвовал.
Anatoly Podgoretsky (2006-10-30 19:45:00) [2]> Shaman_ (30.10.2006 19:33) [35]
Если не будет отдельного экземпляра, то надобность в тестах пропадает.
А вот с отдельными, жесткое тестирование покажет точно.
Shaman_ (2006-10-30 19:33:00) [3][34] Anatoly Podgoretsky
да это понятно :)
я говорил про то, что даже используя отдельный экземпляр ADOConnection в каждом потоке я бы не был на 100% уверен что будет стабильная работа. Не знаю как с ADO. В свое время были трудности с отдельными экземплярами коннектов на MySQL
Думаю только тестированием можно выявить возможные проблемы
Anatoly Podgoretsky (2006-10-30 19:20:00) [4]> Shaman_ (30.10.2006 18:54) [29]
Потоко безопасность ADOConnection означает, что в каждом потоке свой
экземпляр. Если один на все то о потокобезопасности говорить не приходится,
или по отсутсвию такое или по причине отсутствия потоковой работы.
Anatoly Podgoretsky (2006-10-30 19:14:00) [5]> sniknik (30.10.2006 17:39) [25]
Про что и речь.
Зачем потоки? А что бы було.
Anatoly Podgoretsky (2006-10-30 19:13:00) [6]> Arm79 (30.10.2006 17:25) [22]
Можно, сколько угодно, но только по очереди
Anatoly Podgoretsky (2006-10-30 19:11:00) [7]> Arm79 (30.10.2006 17:11) [14]
> в ТЗ, сказано что приложение не должно использовать более одного коннекта
> к базе. :)
> далее, в требованиях идет масимально оперативное получение данных и
> распределение этих данных по получателям.
Что сразу приходит в противоречие, здесь поток не требуется, все потоки
будут выполняться строго последовательно, пока не закончится один запрос,
другие будут ожидать.
Anatoly Podgoretsky (2006-10-30 19:07:00) [8]> Arm79 (30.10.2006 17:01) [12]
А что другое тебе даст ответ?
Ведь одну и туже вещь можно организовать по разному.
Shaman_ (2006-10-30 18:54:00) [9]Вообще я бы потестировал даже с отдельными экземплярами ADOConnection Потоки частенько выдают сюрпризы...
Arm79 (2006-10-30 17:55:00) [10]Ясно, все равно спасибо
Буду думать.
sniknik (2006-10-30 17:51:00) [11]нет, скорее к тому чтобы не делать выборок в потоках... [24]
а вообще задачи то я не знаю, конкретики, что за сколько времени должно делаться тоже, как могу советовать?
Arm79 (2006-10-30 17:42:00) [12]Если Если я правильно понял - вы предлагаете начхать на требование одного коннекта и сделать столько, сколько нужно потоков?
sniknik (2006-10-30 17:39:00) [13]> есть ли возможность организовать работу нескольких потоков от одного коннекта?
и еще я не уверен что это чтонибудь даст, скорее всего ядро ADO просто поставит конкурирующий запрос в очередь (если потокобезопасно, и это там отслежено), в худшем случае рухнет, в еще более худшем, просто ужасном случае будет зациклена на ожидание самой себя, и время выборки вырастет во много раз но будет работать (неявная логическая ошибка, программист проверит на десятке записей, вроде работает на в реале на тысячах будет подвисать на чем дальше тем больше... т.к. не успеет обработать одно а там другой запрос... и т.д. до полного коллапса. явная ошибка лучше. ей можно в морду ТЗ-составителям ткнуть.).
sniknik (2006-10-30 17:32:00) [14]> есть ли возможность организовать работу нескольких потоков от одного коннекта?
я вообще не уверен что потоки здесь нужны (для выборки), может для обработки еще ладно, а выборку лучше асинхронно делать (дать самому ADO потоки поделать)
Arm79 (2006-10-30 17:27:00) [15]
> sniknik © (30.10.06 17:23) [21]
> > основное время - получение данных. Там перегруженная система.
>
> ну еще бы, если там все по таким требованиям написано...
> с главной целью загрузить систему а не решить задачу...
>
>
> как в армии,
> - подметать плац будете ломами...
> - а вениками не лучше?
> - мне не нужно лучше, мне нужно чтобы вы @.....@
:))))
я знаю, вы плохого не посоветуете, но ведь ваша критика в данном случае неконструктивна - я на ТЗ повлиять не могу.
А система действительно организована не самым удачным образом. Но она работает. И у нее свои правила работы.
Arm79 (2006-10-30 17:25:00) [16]допустим ТЗ неправильное, пусть
> логика задачи требует то можно делать и больше, вплоть до
> "сколько надо".
есть ли возможность организовать работу нескольких потоков от одного коннекта?
sniknik (2006-10-30 17:23:00) [17]> основное время - получение данных. Там перегруженная система.
ну еще бы, если там все по таким требованиям написано... с главной целью загрузить систему а не решить задачу...
как в армии,
- подметать плац будете ломами...
- а вениками не лучше?
- мне не нужно лучше, мне нужно чтобы вы @.....@
Arm79 (2006-10-30 17:21:00) [18]
> Последовательное выполение в цикле не катит, тк процесс
> получения данныхдля каждого из получателей занимает от
> 1 до 15 секунд(в особых случаях и гораздо большее время).
> Таким образом интервал обновления информации для каждого
> получателя может достигать в штатном режиме работы до 45
> секунд, что непримлемо.
еще раз, не обработка, а получение
sniknik (2006-10-30 17:20:00) [19]> Там есть четкое требование - один коннект
вообщето это правильное требование, довольно уместное, неуместно только его месторасположение.
но и это не безоговорочное правило, если логика задачи требует то можно делать и больше, вплоть до "сколько надо".
Arm79 (2006-10-30 17:19:00) [20]
> sniknik © (30.10.06 17:17) [17]
> господя, да за 15сек простая выборка миллионов на пять записей
> на клиента сделается, на довольно среднем компьютере...
> что же вы там передаете болезные, что аж на 45 сек, рассчитываете
> на 4х процессорном сервере...
не мы :)
основное время - получение данных. Там перегруженная система.
распределение данных проходит быстро
а 4-хпроцессорный сервер - ну какое железо есть, такое и используем. специально под программу его не заказывали, на складе нашелся :)
| |
Страницы: 