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
