Re: apache:session and mod perl

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

From: Perrin Harkins
Subject: Re: apache:session and mod perl
Date: 17:57 on 30 Dec 2004
Chris Ochs said:
> The issue I am having is that the postgresql store doesn't do any
> locking

It should.  It uses "SELECT FOR UPDATE" which grabs an exclusive lock on
the row in question until a commit is issued.  A::S doesn't issue the
commit, so you have to do that yourself.  Have you been messing with
isolation levels in a way that would defeat the SELECT FOR UPDATE read
lock?

> What is happening is when a page that is loaded loads other pages
> (such as a frameset), sometimes the request for the first page doesn't
> finish before the other requests have already read the session data.

This can be a problem with multiple browser windows, fast reloads, etc. 
Even without frames, you always have to expect concurrent access.

> It goes like this.
>
> - Request 1 fetches session
> - Request 2 fetches session
> - Request 1 changes some session information
> - Request 1 writes out session info
> - Request 2 writes out session info
>
> In our case a flag stating whether a user is logged in or not is
> stored in the session.  If Request 1 logs out a user, Request 2 flags
> the user as logged in again when it writes out the session data.

So you have a lost update problem.  There is probably a way to structure
things to avoid this (maybe not using sessions for it), but some form of
mutually exclusive locking would fix it, at the expense of making your
site slower, since each frame will have to wait for its turn.  You might
try to make your code avoid loading sessions in frames where they are not
absolutely needed.

> Solutions I have thought of so far include..
>
> 1. Switch back to file based sessions, not what I want.

The thing that makes the difference here is really the locking module. 
Take a look at the code inside Apache::Session::Postgres.  It uses the
Null locking module because Postgres is supposed to handle the locking. 
You could have it use the locking from the file-based or MySQL-based
sessions if you wanted to.  Apache::Session::Flex makes this easy to
specify.

> 2. Keep a separate pool of cached connections just for the session
> database, and have those connections use a transaction isolation level
> that guarantees no dirty reads.

You're allowing dirty reads?  That's not the normal isolation level for
Postgres.  That is likely the source of your problems.  Can you change
that to the default level, or is there something else that will break?

- Perrin


        -- 
        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

(message missing)

apache:session and mod perl
Chris Ochs 07:42 on 30 Dec 2004

Re: apache:session and mod perl
Octavian Rasnita 08:00 on 30 Dec 2004

Re: apache:session and mod perl
Chris Ochs 08:09 on 30 Dec 2004

Re: apache:session and mod perl
Perrin Harkins 17:57 on 30 Dec 2004

Re: apache:session and mod perl
Chris Ochs 21:15 on 30 Dec 2004

Re: apache:session and mod perl
Perrin Harkins 22:04 on 30 Dec 2004

Re: apache:session and mod perl
Chris Ochs 05:44 on 31 Dec 2004

Re: apache:session and mod perl
Chris Ochs 07:41 on 31 Dec 2004

Re: apache:session and mod perl
Chris Ochs 17:51 on 31 Dec 2004

Re: apache:session and mod perl
Perrin Harkins 23:40 on 03 Jan 2005

Generated at 12:16 on 16 Jan 2005 by mariachi v0.52