многопоточность и БД

← →
Quantum (2006-01-18 16:40) [0]

Приветствую мастеров.
Задача:
Есть БД (к примеру под firebird).
Есть прилжение, к которому по сети цепляются куча клиентов.
Это приложение обращается к бд, читает/записывает какие либо данные и передает клиенту.
Собсно все стандартно.
Вопрос в том, как организовать многопоточную работу всего этого? Нужно ли создавать отдельное подключение к бд? Нужно ли синхронизовать потоки или этим займется firebird?

Вобщем другими словами вопросто такой: Не подскажите ли какие статейки или примеры по сабжу? =)

← →
Johnmen © (2006-01-18 16:41) [1]

ibase.ru

← →
Quantum (2006-01-18 16:50) [2]

Спасибо за ресурс, он можно немного обнаглеть? =)
Нельзя ли поточнее ссылочку? потому как там очень много документации и по заголовкам не всегда понятно о чем статья...
Мне бы хотя бы базовую информацию по сабжу...(отдельно в БД и в многопоточности вобщем то не новичек но вот вместе не сталкивался...)

← →
Johnmen © (2006-01-18 16:56) [3]

Там (ibase.ru) есть хороший поиск, от яндекса.

← →
Quantum (2006-01-18 16:58) [4]

Но по многопоточности ничего не находит...(

← →
Desdechado © (2006-01-18 18:51) [5]

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

← →
Quantum (2006-01-19 06:35) [6]

ОК. Буде считать что для начала подойдет и такое...
Ну а по поводу синхронизации потоков? Мало того что он в очередь все ставит - мне придется следить еще чтоб потоки не обращались одновременно к компоненту который работает с FB ? Но это же одни блокировки по всему приложению.....?
а если подключения делать отдельные - оно же относительно тяжко будет идти...?

"разделяемый пул собственного управления"
а вообще через FB API можно как либо реализовать многопоточность?

ну не верится как то чтоб к примеру какие нибудь крупные серверы приложений при обращении к БД создавали отдельное подключение на каждого клиента....
если к примеру надо писать лог работы сервера и подключений к нему...

← →
Desdechado © (2006-01-19 11:14) [7]

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

← →
Quantum (2006-01-19 13:43) [8]

Хм... А что, это мысль! Надо ее подумать хорошенько... Спасибо =)

Никто не хочет еще высказаться по данной теме? =)

← →
ЮЮ © (2006-01-20 04:15) [9]

> Никто не хочет еще высказаться по данной теме? =)

А смысл делать трехзвенку, если каждый пользователь "рвется" к серверу БД?. Тогда уж делай клиент-сервер.

← →
Виталий Панасенко (2006-01-20 09:20) [10]

> ЮЮ © (20.01.06 04:15) [9]
>
> > Никто не хочет еще высказаться по данной теме? =)
>
>
> А смысл делать трехзвенку, если каждый пользователь "рвется"
> к серверу БД?. Тогда уж делай клиент-сервер.

Правильно ! И весь это геморрой отпадет сам собой.

← →
Sergey13 © (2006-01-20 10:29) [11]

Непонятно, зачем вообще нужна эта многопоточность? Какова цель всего этого? Сервер то все равно один.

Больших семь шапок из овцы не выкроишь никак. (с) Маршак (кажется)

← →
Tomkat (2006-01-20 12:00) [12]

еще есть понятия Classic и Super Server
Один делает большой канал на всех юзеров, второй каждому клиенту по каналу выделяет

← →
Quantum (2006-01-20 15:40) [13]

нее... вы не поняли =)

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

клиент обращается к "серверу приложений" а тот уже при необходимости лезет на сервер...

просто если клиентов будет 2-3 - подождут в очереди не умрут...а если 200-300 то уже как то долговато ждать то...

> Sergey13 © (20.01.06 10:29) [11]
>
> Непонятно, зачем вообще нужна эта многопоточность? Какова
> цель всего этого? Сервер то все равно один.

так клиентов то много... в сетевой части используется Indy потому каждый клиент сам по себе на сервере приложений - отдельный поток...
и как мне делать? передавать запрос в главный поток и из него выполнять? помоему еще больше гимор...
из каждого потока делать свое соединение? а не сильно ли накладно это будет для системы? в смысле ресурсов именно на открытие_соединения...
собсно само соединение клиента может длиться от пары секунд до суток и более...а клиентов самих в пределах 1000 пока...

← →
Sergey13 © (2006-01-20 15:43) [14]

2[13] Quantum (20.01.06 15:40)
Если клиентов так много, то сервер БД выбран несколько неудачно. Он отличный сервер, но не в таких масштабах. ИМХО.

← →
Виталий Панасенко (2006-01-20 15:53) [15]

> Sergey13 © (20.01.06 15:43) [14]
> 2[13] Quantum (20.01.06 15:40)
> Если клиентов так много, то сервер БД выбран несколько неудачно.
> Он отличный сервер, но не в таких масштабах. ИМХО.

Classic+Многпроцессорный сервер с приличным ОЗУ.. Не все же 1000 одновременно будут грузить сервер.. а там, кто его знает.. Сам с таким количеством не сталкивался лично, может и туплю. А ведь при DCOM можно ведь пускать копию сервера приложения для кождого клиента? Или опять туплю ?

2[15] Виталий Панасенко (20.01.06 15:53)
Не в этом дело. Я бы недоверил работу 1000 человек серверу, базу которого можно восстановить только на дату последнего бэкапа. Пусть даже каждую ночь бекапить. Потерять работу целого дня - не все могут себе это позволить.

← →
Quantum (2006-01-20 16:00) [17]

Кстати про Firebird я в принципе К ПРИМЕРУ сказал...то есть можновыбрать и другой сервер...
а что до количества клиентов -то это теоретический_максимум....
то есть практически больше 20-50 одновременно вряд ли будут...хотя бы потому что врема соединения в основном небольшое...

главный вопрос все же в том как это правильней и "красивей" реализовать...

> Quantum (20.01.06 16:00) [17]

> про Firebird я в принципе К ПРИМЕРУ сказал

При данных условиях и при условиях "халявности" на сей момент FB-серверного софта выбор FB не так уж и плох.

> как это правильней и "красивей" реализовать

Каждый кодовый поток процесса AppServer"а при данных условиях обязан открыть отдельную свою сессию доступа к FB-серверу, отдельные свои транзакции и отдельные свои объекты обращения к БД в контексте конкретной своей сессии и конкретной своей транзакции.

← →
Quantum (2006-01-21 10:06) [19]

Значит всё же отдельные подключения... Ну в принципе я уже так и подумывал...
Спасибо всем большое а участие. =)

Digitman © (20.01.06 16:59) [18]
Халявность при таком количестве клиентов уже не является преимуществом. На первый план выъодят уже другие соображения, то же восстановление с точностью до секунды.

многопоточность и БД Найти похожие ветки