|
ru.perl
- RU.PERL ----------------------------------------------------------------------
From : Andrey Sapozhnikov 2:5020/400 16 Sep 2002 18:39:56
To : Ildar Gabdulline
Subject : Re: persistent DBI connections
--------------------------------------------------------------------------------
Ildar Gabdulline wrote:
> Как можно реализовать следующую вещь ?
> 1. perl script, постоянно висящий в памяти создает N DBI соединений к ORACLE
> и держит их в pool
> 2. другие perl - скрипты (специфика применения такова, что их число - сотни
> и тысячи, причем рождаются они часто) запрашивает соединение с БД у первого
> скрипта (механизмы могут быть разные - файл, shm)
> при необходимости работать с БД
> 3. соединение (т.е. все данные необохимые для его использования ) передается
> скрипту, который их и использует
> 4. в конце работы соединение возвращается обратно в pool
Все это легко реализовавалось БЫ, если БЫ не одно маленькое HО:
perldoc DBI:
...
Note that some databases, including Oracle, don't sup-
port passing a database connection across a fork.
...
насколько я понимаю, это ограничение Ораклового клиента и соединение
открытое в одном процессе не может быть передано в другой. Если даже
соединение и будет передано в дочерний процесс и отработает как
положено, то не факт, что оно отработает во второй раз. В процессе
работы с базой, в дочернем процессе меняются некоторые данные в
структурах Ораклового клиента, и эти изменения никак не отобразятся в
аналогичных структурах в родительском процессе. В итоге - родительское
соединение становится нежизнеспособным.
> Кстати, вопрос по теме касательно DBI::ProxyServer - что надо сделать, чтобы
> dbiproxy кешировал соединения ?
> (использование в скрипте connect_cached не помогает, connection все равно
> закрывается при disconnect или завершении скрипта).
и не поможет. прокси-сервер (если он только не работает в вырожденном
single-mode) порождает отдельный процесс на каждое открытое прокси-соединение
и, соответственно, сталкивается с тем же ограничением на открытие соединения
с БД в родительском процессе.
Рекомендаций выносить не буду, но как поступил бы в этом случае я :)
1. Подумал бы над возможностью multithread реализации в рамках
одного процесса (perl + ithreads) и потестировал совместим ли
Оракловый клиент с этим делом.
2. При неудаче, откатился бы к pre-forked версии. То есть стартует
процесс, ветвится на 2000 идентичных, в каждом открывается одно
соединение с базой и управляющий сокет на прослушивание. Свободный
от работы клиент получает по этому сокету команду на вызов скрипта
и вызывает его HЕ порождая дочернего процесса. Вероятно скрипты в данном
случае должны быть похожи на mod_perl Apache::Registry скрипты.
По окончании работы скрипта продолжаем слушать управляющий сокет.
Система до боли напоминает Apache+mod_perl и требует изрядных ресурсов
памяти, впрочем в пределе и ваша модель требовала бы тех же
двух тысяч перловых процессов в памяти.
Андрей
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
Re: persistent DBI connections 