This question could go to one of several different lists, but I
thought this might be a good place to start.
I have an application based on mod perl and the Template Toolkit. For
session tracking I am using Apache::Session with the postgresql
backend store.
The issue I am having is that the post
If this happens only in pages with frames, try creating a page without
frames.
Teddy
- Original Message -
From: "Chris Ochs" <[EMAIL PROTECTED]>
To:
Sent: Thursday, December 30, 2004 9:42 AM
Subject: apache:session and mod perl
This question could go to one of several
On Thu, 30 Dec 2004 10:00:32 +0200, Octavian Rasnita <[EMAIL PROTECTED]> wrote:
> If this happens only in pages with frames, try creating a page without
> frames.
Umm no, I want a solution not a work around. This application is used
by a lot of people on a lot of different sites with the file bac
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 mess
> 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
>
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 d
>
> > 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
> > 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 go
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 be
On Fri, 2004-12-31 at 09:51 -0800, Chris Ochs wrote:
> 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.
There is no such thing as a write lock for the Postgr
10 matches
Mail list logo
