Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Perl: Общие вопросы > Разделение DBI соединений между потоками.


Автор: sir_nuf_nuf 25.3.2008, 19:33
Вопросы: 
как минимизировать число подключений к базе данных ?
как это можно сделать руками без готовых модулей ?

Имеем: apache2, mod_perl2, есть CPAN =)

готовые варианты:
Apache::DBI    Apache::DBI::Cache    Apache::BabyConnect

все эти модули предоставляют persistent connection - это замечательно!
но я так и не нашел в документации разделяются ли эти соединения между потоками.

ясно, что каждый _процесс_ apache обязан иметь свое соединение, а потоки ?

неясно какую модель потоков использует mod_perl2,
можно ли разделять переменные с помощью
Код

use threads::shared;

и написать собственный пул для DBI соединений или необходимо делать разделение на уровене C кода ?

Автор: vadiml 25.3.2008, 20:50
я фактически ответил в http://forum.vingrad.ru/index.php?showtopic=202438&view=findpost&p=1455109 smile

Автор: sir_nuf_nuf 26.3.2008, 00:38
сорри, но фактически вы не сказали ничего нового.

Автор: ginnie 26.3.2008, 11:54
sir_nuf_nuf, не подскажите, чем, по-вашему, потоки отличаются от процессов с точки зрения использования БД?

Автор: sir_nuf_nuf 26.3.2008, 15:06
Разные процессы - имеют разное адресное пространство -> они не могут разделять db handle. 
т.е. приницпиально не возможно использовать одно соединение для нескольких процессов ( ну если не думать в сторону POSIX shmem)

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

в j2ee часто делаю так: создают pool соединений с базой, каждый поток может брать от туда соединения и возвращать 
обратно. при этом соединения остаются всегда открытыми. Т.к. соединение нужно потоку не 100% времени, то число
соединений может быть меньше числа потоков.

разница между потоками и процессами в это отношении - это адресное пространство.

Автор: konstant1n 6.4.2008, 10:02
некоторое время назад тоже думал на над этой проблемой.   Если кратко то легко проблема  внутри mod_perl не решается, т.к.  нет простого механизма доступа к одним и тем-же данным из разных потоков апача.  

проблема решилась с помощью стороннего софта который организует connection pool.  В нашем случае это pgbauncer, прокси-пул для постгреса.  https://developer.skype.com/SkypeGarage/DbProjects/PgBouncer    Для постгреса есть еще pgpool и pgpool-II.  Также pgODBC драйвер под виндой умеет делать   connection pool.    На сколько я знаю MySQL ODBC драйвер тоже поддерживает connection pool.   Про другие базы и конекторы не скажу т.к. не знаю.

Если охота делать из под mod_perl  то смотрите на модули APR::Pool и APR::Table которые являются обертками к apr_pool_t и apr_table_t ( http://apr.apache.org/docs/apr/1.2/ )  С их помощью можно обмениваться данными через внутренние структуры данных апача.   Что меня остановило так это отсутствие примеров как работать со всем этим делом, а время в в проекте было ограничено.   В доке показан лишь частный случай создание APR::Pool уровня запроса, а тут нужен уровень процесса.

Так же советую проанализировать ситуацию на предмет "а оно надо?", поясню:
 1) если идет речь о высоко-нагруженном веб сервисе то реально открытое соединение к базе нужно всем процессам апача т.к. они должны не спать а занимается делом -- обрабатывать данные,  соответственно постоянно читать/писать в базу.   Задачу обработки "медленных" клиентов и очереди лучше отдать какой-нибудь  proxy.     

 2) если имеем дело с небольшой  нагрузкой -- может и так сойдет, скорее всего узкое место будет не в количестве конектов к базе.

  
  


Автор: sir_nuf_nuf 7.4.2008, 07:17
Спасибо! разумный ответ!

на самом деле не сильно надо. =)
просто смущала неясность - как такое организовать.. ответ не радостный - легко не получится.

Автор: gcc 25.4.2009, 17:42
случайно увидел

http://search.cpan.org/~darnold/DBIx-Threaded-0.10/lib/DBIx/Threaded.pm

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)