> > I tried setting Lock to File instead of Null, but there is some sort > > of contention issue because after the first request all other requests > > hang like they are waiting for a lock to be release. > > This usually means you have a scoping bug in your code. If the session > object never goes out of scope, it will not release the lock.
I put some loggin into apache::session::lock::file, and then switched between using apache::session::file and apache::session::flex with postgres and Lock set to File. With postgres it calls acquire_read lock a bunch of times in a row with an acquire_write_lock thrown in and then something blocks. Using apache::session::file it alternates correctly and doesn't do that. There has to be some logic in apache::session that is different than apache::session::file. Here is a log when using apache::session::file. I put the pid in front. 96836 acquire_read_lock 96836 acquire_write_lock 96836 release_all_lock 96836 DESTROY 96836 release_all_lock 96822 acquire_read_lock 96822 acquire_write_lock 96822 release_all_lock 96822 DESTROY 96822 release_all_lock 96836 acquire_read_lock 96836 acquire_write_lock 96836 release_all_lock 96836 DESTROY 96836 release_all_lock Here is a log using flex with postgres and Lock set to File. 96824 acquire_read_lock 96834 acquire_read_lock 96826 acquire_read_lock 96824 acquire_write_lock 96822 acquire_read_lock I'm not sure exactly what pages were being called in the log snippets above, but this pattern is always the same. Chris -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
