Chris Ochs said: > I have found three things that need to be worked around like this in > order to use this approach. One is frames like you said, the other is > not pulling in stylesheets via an href, and the other is making sure > images are not loaded through mod perl. If I do all of that I don't > have any problems. I still don't like it, but it might be our only > option.
It's not your only option, but you really don't want to be pulling in sessions for things like CSS and images, or serving them through mod_perl. > 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. > Also, I found out through further testing that Apache::Session doesn't > do exclusive locking on read, only write. Apache::Session::Store::Postgres uses an exclusive lock via SELECT FOR UPDATE, and it grabs the lock when you load the session. Other subclasses behave differently. I don't believe the "Transaction" option has any effect on the Postgres subclass. > And that also > means that there isn't any need for additional locking with postgresql > because using SELECT FOR UPDATE basically does the same thing as the > file locking. 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. - 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
