Re: apache:session and mod perl

[prev] [thread] [next] [Date index for 2004/12/31]

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 <snacktime@xxxxx.xxx> 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