ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: использование BerkeleyDB в фильтре



Вы не совсем правы.

>Berkeley DB handles should not be shared across process forks, each
forked child should acquire its own Berkeley DB handles.
(http://www.oracle.com/technology/documentation/berkeley-db/db/ref/build_unix/notes.html)

Насколько я понимаю, воркер - отдельный процесс с одним потоком,
поэтому использование DB_THREAD не обязательно, но следует создавать
DB environment с поддержкой транзакций (с флагом DB_INIT_TXN) для
конкурентного выполнения операций чтения-записи.

Отсюда следует вывод, что DB->open следует делать в callback'е для
'init process', а DB-close - в 'exit process'

Если не прав, то просьба поправить.

2008/3/12 Alex Tutubalin <lexa@xxxxxxx>:
> > > > Я мало работал с BDB, но под Апачём я открывал базу в фазе
>  > > > "module initializer" в основном процессе.
>  > > Э, в read-write или в RO?
>  > У меня был RO. И база 1.95.
>
>  Ну, 1.95 параллельный read-write не поддерживает, enviroment у нее
>  нету, а структуры данных в памяти - ну, скопировались, отлично.
>
>
>  > > если нужен read-write из нескольких процессов, то нужно все делать
>  > > так, как Sleepycat/Oracle прописал - в основном процессе инициализировать
>  > > enviroment, в воркерах - работать с этим enviroment.
>  >
>  > То есть, именно так, как я и описал - всё открытие/закрытие в основном
>  > процессе.
>  Я уже написал "абсолютно не так" (ибо я бы переоткрывал все в дочерних
>  процессах отдельно), но в оракловых форумах пишут, что если открывать
>  с DB_THREAD, то все будет отлично и после fork()
>
>
>
>
>  Алексей Тутубалин
>  mailto: lexa@xxxxxxx
>  Web: http://www.lexa.ru/lexa
>
>


 




Copyright © Lexa Software, 1996-2009.