Re: apache:session and mod perl

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

> 
> > 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.
> 
If it is a scoping issue it's probably in one of the Apache::Session
modules, or maybe I'm not supplying all the necessary parameters when
using File locking with Postgresql.  Literally all I did is change
Lock to File instead of Null and that's it.  The session is kept in a
global request object I use for all variables that need to be passed
around.  In the cleanup handler I untie the session and undefined the
request object, and log it all with log4perl.  If there were scoping
issues with the global request object, it would show up all over the
place.  I just figured that File locking wasn't supported or tested
with the Postgresql backend store, so I didn't spend any more time on
it.


> Yes, you should not need anything more than the Postgres locking.
> 
> > I use the default isolation in postgresql.
> 
> Then it really should be shielding you from this problem.  Make sure your
> scoping is correct (you could throw a warn into the A::S DESTROY() sub to
> make sure it is getting called) and make sure you are issuing a commit
> somewhere in there to save your changes.

SELECT FOR UPDATE doesn't block reads.

I put in the File backend store with the Transaction argument and it
puts an exclusive lock on reads, which makes everything work as I
wanted it to.  Now I will go back and look closer at Apache::Session
and see if the File locking is supported for the Postgresql store.

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