потокобезопасность класса TADOConnection

← →
Arm79 © (2006-10-30 16:29) [0]

Уважаемые мастера

Насколько мне известно АДО само по себе потокобезопасно.
А вот насколько потокобезопасны стандартные компоненты для работы с АДО? Особенно интересует ADOConnection

Спасибо.

Сейчас идет этап проектирования, не хотелось бы ошибаться в самом начале.

← →
Anatoly Podgoretsky © (2006-10-30 16:33) [1]

Стресс тестирование. Словам не верь.

← →
Сергей М. © (2006-10-30 16:42) [2]

> Особенно интересует ADOConnection
>

Объект этого класса должен быть создан индивидуально для каждого потока.

← →
Arm79 © (2006-10-30 16:46) [3]

в общем то ответы те же что я и думал.

тогда уточняющий вопрос:

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

← →
Сергей М. © (2006-10-30 16:49) [4]

> Arm79 © (30.10.06 16:46) [3]

> неужели для каждого из потоков открывать свое соединение?

Да.

А что тут сложного ?

← →
Anatoly Podgoretsky © (2006-10-30 16:49) [5]

> Объект этого класса должен быть создан индивидуально для
> каждого потока.

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

← →
Anatoly Podgoretsky © (2006-10-30 16:51) [6]

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

Не обязательно, но это уже будет однопоточное приложение, все будет последовательно выполняться и уж точно нарвершься на неприятности, если кто то вздумает изменить. Экземляр то один!

← →
Arm79 © (2006-10-30 16:51) [7]

> Сергей М. © (30.10.06 16:49) [4]
>
> > Arm79 © (30.10.06 16:46) [3]
>
>
>
> > неужели для каждого из потоков открывать свое соединение?
>
>
>
> Да.
>
> А что тут сложного ?

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

← →
Anatoly Podgoretsky © (2006-10-30 16:52) [8]

Не получится, только если у каждого потока свой набор компонент и переменных, включая TADOConnection

← →
Сергей М. © (2006-10-30 16:53) [9]

> требование такое - один коннект на приложение.

Эт чего, ТЗ что ли ?

← →
Arm79 © (2006-10-30 16:58) [10]

Да, именно ТЗ.

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

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

← →
Anatoly Podgoretsky © (2006-10-30 16:59) [11]

Ответ получил?
Если да, то делай тесты.

← →
Arm79 © (2006-10-30 17:01) [12]

> Anatoly Podgoretsky © (30.10.06 16:59) [11]
> Ответ получил?
> Если да, то делай тесты.

Да, единственный совет, который я получил - организовать стресс-тестирование :)))

Будем делать.

← →
Сергей М. © (2006-10-30 17:02) [13]

> Arm79 © (30.10.06 16:58) [10]
>
> Да, именно ТЗ.
>

И в том самом ТЗ (не тобой, разумеется, изобретенном, а тебе волею господней данное для разработки ТР), конечно же, фигурирует обязательность кучи потоков, каждый из которых волен в люборй секунд времени использовать по своему усмотнрению одну-единственную коннекцию ... Я правильно понял ?)

← →
Arm79 © (2006-10-30 17:11) [14]

в ТЗ, данном может и не волей бога, но по крайней мере архангелом Гавриилом, сказано что приложение не должно использовать более одного коннекта к базе. :)

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

Количество получаетелей в общем случае неограничено, но фактически на данный момент их трое.

Последовательное выполение в цикле не катит, тк процесс получения данных для каждого из получателей занимает от 1 до 15 секунд (в особых случаях и гораздо большее время). Таким образом интервал обновления информации для каждого получателя может достигать в штатном режиме работы до 45 секунд, что непримлемо.

При этом распределение получения информации и ее обработки по потокам на 4-х процессорном сервере дает очень хорошие результаты (есть разработанный прототип для оценки скорости).

Вот такая вот диллема. Либо скорость работы и несколько коннектов, либо отказ от скорости и переход к одному коннекту

← →
sniknik © (2006-10-30 17:13) [15]

в ТЗ не должно указываться как делать, там должно быть расписано, и максимально подробно, что делать, иначе это не ТЗ а фигня какаято, извините....

← →
Arm79 © (2006-10-30 17:15) [16]

> sniknik © (30.10.06 17:13) [15]
> в ТЗ не должно указываться как делать, там должно быть расписано,
> и максимально подробно, что делать, иначе это не ТЗ а фигня
> какаято, извините....

Прошу прощения, какое есть.
Там есть четкое требование - один коннект

← →
sniknik © (2006-10-30 17:17) [17]

господя, да за 15сек простая выборка миллионов на пять записей на клиента сделается, на довольно среднем компьютере... что же вы там передаете болезные, что аж на 45 сек, рассчитываете на 4х процессорном сервере...

← →
Arm79 © (2006-10-30 17:19) [18]

> sniknik © (30.10.06 17:17) [17]
> господя, да за 15сек простая выборка миллионов на пять записей
> на клиента сделается, на довольно среднем компьютере...
> что же вы там передаете болезные, что аж на 45 сек, рассчитываете
> на 4х процессорном сервере...

не мы :)

основное время - получение данных. Там перегруженная система.
распределение данных проходит быстро

а 4-хпроцессорный сервер - ну какое железо есть, такое и используем. специально под программу его не заказывали, на складе нашелся :)

← →
sniknik © (2006-10-30 17:20) [19]

> Там есть четкое требование - один коннект
вообщето это правильное требование, довольно уместное, неуместно только его месторасположение.
но и это не безоговорочное правило, если логика задачи требует то можно делать и больше, вплоть до "сколько надо".

← →
Arm79 © (2006-10-30 17:21) [20]

> Последовательное выполение в цикле не катит, тк процесс
> получения данных для каждого из получателей занимает от
> 1 до 15 секунд (в особых случаях и гораздо большее время).
> Таким образом интервал обновления информации для каждого
> получателя может достигать в штатном режиме работы до 45
> секунд, что непримлемо.

еще раз, не обработка, а получение

← →
sniknik © (2006-10-30 17:23) [21]

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

как в армии,
- подметать плац будете ломами...
- а вениками не лучше?
- мне не нужно лучше, мне нужно чтобы вы @.....@

← →
Arm79 © (2006-10-30 17:25) [22]

допустим ТЗ неправильное, пусть

> логика задачи требует то можно делать и больше, вплоть до
> "сколько надо".

есть ли возможность организовать работу нескольких потоков от одного коннекта?

← →
Arm79 © (2006-10-30 17:27) [23]

> sniknik © (30.10.06 17:23) [21]
> > основное время - получение данных. Там перегруженная система.
>
> ну еще бы, если там все по таким требованиям написано...
> с главной целью загрузить систему а не решить задачу...
>
>
> как в армии,
> - подметать плац будете ломами...
> - а вениками не лучше?
> - мне не нужно лучше, мне нужно чтобы вы @.....@

:))))

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

А система действительно организована не самым удачным образом. Но она работает. И у нее свои правила работы.

← →
sniknik © (2006-10-30 17:32) [24]

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

← →
sniknik © (2006-10-30 17:39) [25]

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

← →
Arm79 © (2006-10-30 17:42) [26]

Если Если я правильно понял - вы предлагаете начхать на требование одного коннекта и сделать столько, сколько нужно потоков?

нет, скорее к тому чтобы не делать выборок в потоках... [24]
а вообще задачи то я не знаю, конкретики, что за сколько времени должно делаться тоже, как могу советовать?

Ясно, все равно спасибо

Буду думать.

Вообще я бы потестировал даже с отдельными экземплярами ADOConnection Потоки частенько выдают сюрпризы...

> Arm79 (30.10.2006 17:01) [12]

А что другое тебе даст ответ?
Ведь одну и туже вещь можно организовать по разному.

> Arm79 (30.10.2006 17:11) [14]

> в ТЗ, сказано что приложение не должно использовать более одного коннекта
> к базе. :)

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

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

> Arm79 (30.10.2006 17:25) [22]

Можно, сколько угодно, но только по очереди

> sniknik (30.10.2006 17:39) [25]

Про что и речь.
Зачем потоки? А что бы було.

> Shaman_ (30.10.2006 18:54) [29]

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

[34] Anatoly Podgoretsky

да это понятно :)
я говорил про то, что даже используя отдельный экземпляр ADOConnection в каждом потоке я бы не был на 100% уверен что будет стабильная работа. Не знаю как с ADO. В свое время были трудности с отдельными экземплярами коннектов на MySQL
Думаю только тестированием можно выявить возможные проблемы

> Shaman_ (30.10.2006 19:33) [35]

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

> используя отдельный экземпляр ADOConnection в каждом потоке я бы не был на 100% уверен что
> будет стабильная работа. Не знаю как с ADO
83-87 (~) потока содержащих по коннекту и т.д. это наш "рекорд" ;о)), но это правда стресс тестирование не проходило... только в рабочем режиме проверялось (ну не ожидали, что клиент столько устройств нацепит, ожидалось это решение под 10 ну максимум 20 устройств, поэтому проверялось на 30ти...), устройства данные получают из mssql, и каждое полностью автономное поэтому решение - вся обработка одного, в отдельном потоке очевидна. (устройства еще и медленные (весы), т.что параллельная загрузка очень кстати, получается все, неважно сколько их, по времени загружаются примерно столько же сколько одни... (вернее полторы/двое последовательно;))
на стабильность не жаловались. тфу, тфу чтоб не сглазить :о))
да, решение/программа не моя, хотя как консультант по ADO я там немного участвовал.

потокобезопасность класса TADOConnection Найти похожие ветки