Скачать: CL | DM;

потокобезопасность класса 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]

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

---

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

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

---

← →
Arm79 ©   (2006-10-30 17:55) [28]

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

Буду думать.

---

← →
Shaman_ ©   (2006-10-30 18:54) [29]

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

---

← →
Anatoly Podgoretsky ©   (2006-10-30 19:07) [30]

> Arm79  (30.10.2006 17:01)  [12]

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

---

← →
Anatoly Podgoretsky ©   (2006-10-30 19:11) [31]

> Arm79  (30.10.2006 17:11)  [14]

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

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

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

---

← →
Anatoly Podgoretsky ©   (2006-10-30 19:13) [32]

> Arm79  (30.10.2006 17:25)  [22]

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

---

← →
Anatoly Podgoretsky ©   (2006-10-30 19:14) [33]

> sniknik  (30.10.2006 17:39)  [25]

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

---

← →
Anatoly Podgoretsky ©   (2006-10-30 19:20) [34]

> Shaman_  (30.10.2006 18:54)  [29]

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

---

← →
Shaman_ ©   (2006-10-30 19:33) [35]

[34] Anatoly Podgoretsky

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

---

← →
Anatoly Podgoretsky ©   (2006-10-30 19:45) [36]

> Shaman_  (30.10.2006 19:33)  [35]

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

---

← →
sniknik ©   (2006-10-30 20:15) [37]

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

---

Страницы: 1 вся ветка

Скачать: CL | DM;



Память: 0.55 MB
Время: 0.038 c