On Wed, May 23, 2001 at 09:11:53PM +0200, Robert wrote:
> Is anybody here using Apache::Session/Postgres combination without
> problems? If so, could you be so kind as to post your configuration? If
> not, how far did you get last time you tried? Is anybody interested in
> using it at all?
finally got around to looking at this myself..
Apache::Session::Store::Postgres does a SELECT FOR UPDATE on
materialize. this locks the database row until the end of the
transaction. unless update, remove, insert or DESTROY are called,
there is no end of the transaction, which means you can deadlock
sometimes..
(Apache::Session is designed to be DESTROYed after use, but
HTML::Embperl::Session doesn't do this)
as i see it, the "proper" fix is to either:
1. write a Lock::Postgres class that ends the transaction on
release_all_locks (or release_{read,write}_locks)
2. reimplement HTML::Embperl::Session to create and destroy
Apache::Session objects, rather than reusing them. (this is how
Apache::Session is expecting to be used)
3. add some sort of cleanup() function to Apache::Session::Store
classes, and use this as HTML::Embperl::Session uses its.
(2) is the only one which doesn't require changing Apache::Session, so
it is probably the best choice (and should cleanup some of the hacks
in HTML::Embperl::Session). gerald, feeling bored? ;)
i reused a Store::File hack to quickly do (3), by implementing close():
(Apache::Session::Store::Postgres:)
# this is a hack inherited from Store::File and required for
# HTML::Embperl::Session
sub close {
my $self = shift;
if ($self->{rollback_on_destroy}) {
# we may as well be explicit about these things..
$self->{dbh}->rollback;
} elsif ($self->{commit}) {
$self->{dbh}->commit;
}
}
(requires my earlier patch which sets rollback_on_destroy if
Transaction=1 was given)
> Sorry if I sound a bit pessimistic - I applied patch Angus Lee posted
> week ago on Embperl list and it almost works, but I still have some idle
> postgres backend hanging around. It's getting really frustrating.
from what i can work out (and i have no clue about databases), its
normal to have one postgres process per apache child process, since
apache keeps the db connection open.
i notice that the postgres processes claim to be "idle in
transaction". i have no idea what this transaction is (the above patch
doesn't change it). i think it would be good to track this down at
some point.
something that has me completely stumped is that occasionally the
session will not be restored correctly (written to database, but they
keep getting a new session each time they try and read it back). when
i add two warn() statements to Store::Postgres (to print the values
returned from the materialize() DBI calls), everything fixes itself
and works fine.
restarting/clearing cookies/etc before adding the lines doesn't fix
the problem, restarting after adding or after removing the lines again
does fix it.. this has happened identically 3 or 4 times now - the
consistency is what gets me..
robert, i'd be interested in comparing experiences. did you get any
replies from the other lists?
--
- Gus
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
