Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

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

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

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

Quantum (2006-01-21 10:06:00) [2]
Значит всё же отдельные подключения... Ну в принципе я уже так и подумывал...
Спасибо всем большое а участие. =)

Digitman (2006-01-20 16:59:00) [3]

> Quantum (20.01.06 16:00) [17]

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

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

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

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

Quantum (2006-01-20 16:00:00) [4]
Кстати про Firebird я в принципе К ПРИМЕРУ сказал...то есть можновыбрать и другой сервер...
а что до количества клиентов -то это теоретический_максимум....
то есть практически больше 20-50 одновременно вряд ли будут...хотя бы потому что врема соединения в основном небольшое...

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

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

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

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

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

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

Quantum (2006-01-20 15:40:00) [8]
нее... вы не поняли =)

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

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

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

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

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

Tomkat (2006-01-20 12:00:00) [9]
еще есть понятия Classic и Super Server
Один делает большой канал на всех юзеров, второй каждому клиенту по каналу выделяет

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

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

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

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

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

ЮЮ (2006-01-20 04:15:00) [12]

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

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

Quantum (2006-01-19 13:43:00) [13]
Хм... А что, это мысль! Надо ее подумать хорошенько... Спасибо =)

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

Desdechado (2006-01-19 11:14:00) [14]
"разделяемый пул собственного управления" - имелось ввиду, что пока нагрузка маленькая (т.е. одновременных обращений нет), все идет через один коннект
как только появляется еще одно обращение, которое не может быть обслужено из-за занятости коннекта, создается второй коннект и т.д.
для каждого коннекта, кроме первого, создается некий таймер, который считает время неактивности, после чего коннект уничтожается и т.д.

Quantum (2006-01-19 06:35:00) [15]
ОК. Буде считать что для начала подойдет и такое...
Ну а по поводу синхронизации потоков? Мало того что он в очередь все ставит - мне придется следить еще чтоб потоки не обращались одновременно к компоненту который работает с FB ? Но это же одни блокировки по всему приложению.....?
а если подключения делать отдельные - оно же относительно тяжко будет идти...?

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

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

Desdechado (2006-01-18 18:51:00) [16]
AFAIK, клиент FB не может в одном подключении обрабатывать параллельно несколько запросов, он их в очередь выстраивает
если такое подходит, то можно обойтись одним подключением, если нет - делать много подключений
на каждого свой или разделяемый пул собственного управления - это уж как руки работают и задача стоит

Quantum (2006-01-18 16:58:00) [17]
Но по многопоточности ничего не находит...(

Johnmen (2006-01-18 16:56:00) [18]
Там (ibase.ru) есть хороший поиск, от яндекса.

Quantum (2006-01-18 16:50:00) [19]
Спасибо за ресурс, он можно немного обнаглеть? =)
Нельзя ли поточнее ссылочку? потому как там очень много документации и по заголовкам не всегда понятно о чем статья...
Мне бы хотя бы базовую информацию по сабжу...(отдельно в БД и в многопоточности вобщем то не новичек но вот вместе не сталкивался...)

Johnmen (2006-01-18 16:41:00) [20]
ibase.ru

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »