I know what's happening now, it dawned on me after I wrote this last night.
A deadlock happens when you have an updater that acquires a write lock, but it's waiting for the first updater that is also in a SELECT FOR UPDATE but has not yet acquired a write lock. The first updater can't finish because it can't acquire a write lock that the second updater has already obtained, and the second updater can't update until the first one finishes, which it can't. Which also explains why Apache::Session::Flex doesn't list File as one of the supported Lock options. A workable hack would probably be to have Apache::Session::Lock::File always set Transaction to 1 if the backend store was postgres. Chris On Thu, 30 Dec 2004 23:41:16 -0800, Chris Ochs <[EMAIL PROTECTED]> wrote: > > > 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
