You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Robert <ro...@robert.cz> on 2001/05/23 21:11:53 UTC
Sessions with Postgres
Hi,
sorry for crossposting. I'd like to use Apache::Session with Postgres
as a backend (from HTML::Embperl if possible), but I'm still having
problems. People on these lists complain from time to time that they
have problems with this combination but searching archives don't give
many advices / just list of problems...
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?
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.
- Robert
Re: Sessions with Postgres
Posted by Vivek Khera <kh...@kcilink.com>.
>>>>> "r" == robert <ro...@robert.cz> writes:
r> Is anybody here using Apache::Session/Postgres combination without
r> problems? If so, could you be so kind as to post your configuration? If
Yes, I am.
I posted mine either here or on one of the postgres mailings lists
just a few days ago.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Vivek Khera, Ph.D. Khera Communications, Inc.
Internet: khera@kciLink.com Rockville, MD +1-240-453-8497
AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: Sessions with Postgres
Posted by Wim Kerkhoff <wi...@merilus.com>.
Angus Lees wrote:
>
> 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..
Your comments prompted me to set this up myself and give it a better try
then last time. I'll be needing session management soon anyways.
> > 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.
I just your patch from May 11, added the
Apache::Session::Store::Postgres::close function, and still postgres
backends that are hanging somewhere in the transaction.
> 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.
Isn't this only supposed to happen when using Apache::DBI? I'm not using
Apache::DBI, and still get a postgres process for each apache child
process.
> 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.
I get this behaviour when using %mdat by itself, when using %udat by
itself, and when using them both together.
It could be that its not commiting or rolling back properly. I am seeing
these errors in the apache error logs, which leads me to think its
something in the transaction is not going through properly, and hence
they are sitting there waiting to do something.
FATAL 1: This connection has been terminated by the administrator.
[Tue Jun 26 10:47:45 2001] [warn] [1534]ERR: 32: Line 4: Warning in
Perl code: DBD::Pg::db commit failed: commit
failed at /usr/local/share/perl/5.6.1/Apache/Session/Store/Postgres.pm
line 128.
FATAL 1: This connection has been terminated by the
administrator.
[Tue Jun 26 11:10:37 2001] [warn] [3077]ERR: 32: Line 11: Warning in
Perl code: DBD::Pg::db rollback failed: rollback failed at
/usr/local/share/perl/5.6.1/Apache/Session/Store/Postgres.pm line 128.
Hopefully this information will help someone...
BTW, here are my session settings from startup.pl:
BEGIN {
$ENV{EMBPERL_SESSION_CLASSES} = "Postgres Null Base64";
$ENV{EMBPERL_SESSION_ARGS} = "DataSource=dbi:Pg:dbname=sessions
UserName=postgres Transaction=1 Commit=1";
};
--
Regards,
Wim Kerkhoff, Software Engineer
Merilus, Inc. -|- http://www.merilus.com
Email: wim@merilus.com
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Sessions with Postgres
Posted by Gerald Richter <ri...@ecos.de>.
>
> 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 didn't like the idea of always recreate a session object, because it has
to be done for _every_ request not only the ones that uses sessions. Thats's
the reason, why I only create one session and keep it. Recreating everytime
would cost much too much performance.
The problem from my point of view is, that Apache::Session isn't really
maintaint. While Jeff has done a good work in creating Apache::Session, he
doesn't maintain it very well. I had send many patches and it has taken a
long time until, if at all, they got incoporated. So I started to create
HTML::Embperl::Session, which does what I need for Embperl. (also it copies
a lot of code form Apache::Session itself)
>
> i reused a Store::File hack to quickly do (3), by implementing close():
>
I don't know how to contiune best, but this, I think, should go into
Apache::Session. Using the hack is the short time solution, extenting
Apache::Session would be much better from my point of view.
Gerald
P.S. I am out of office for the next week, so I am not able to answer before
july, 8.
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Sessions with Postgres & Embperl 2.0 EP1COMPAT Flag
Posted by Gerald Richter <ri...@ecos.de>.
>
> I meant posting info we should get the latest CVS tarball so you don't
> have to mail it to all of us by hand.
>
The session code is separated in a module on it's own which isn't in the cvs
yet.
Also the CVS is currently moveing form perl.apache.org to cvs.apache.org and
I didn't have tested the new location...
>
> And when it comes to EMBPERL_EP1COMPAT 1, have well is this tested? I
> have maybe thirty critical virtual servers using Embperl on my
> production server (critical == pays my rent ;-) I'm terrified by the
> idea a page in an obscure corner of some virtserver breaks and I'll find
> it out when customer calls...
>
It uses exactly the same code as 1.3.3. The EP 2 make test, also tests the
compatibility mode, so it should work without problems. Of course not as
many users have used it so far, so there maybe a (very) hidden bug
somewhere, but I don't think so. (I use EMBPERL_EP1COMPAT on my own in some
of our projects, where we need to run old and new code together and I found
nothing what's going wrong so far)
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Sessions with Postgres
Posted by Gerald Richter <ri...@ecos.de>.
>
> I'm back at work (sort of) and I'm glad to see there's progress on the
> Embperl/Session front. Gerald, when there's something you want us to
> test in the CVS, would you post info to this list? I'm looking forward
> too.
>
I have done something. I send it to you with private mail. I thinks it's too
big to send it to the list. If anybody else what's to test, leave me a note.
> Related question: Can Embperl be safely downgraded? Can I install CVS
> or 2.0beta version, test it and when something's wrong just reinstall
> 1.3.3 over it?
Yes, you could do this without problems. You could also use the
EMBPERL_EP1COMPAT Flag to make EP 2.0 behave like EP1
Gerald
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Sessions with Postgres
Posted by Gerald Richter <ri...@ecos.de>.
Hi,
>
> here are first my comments:
>
> - it's a little bit confusing how many things I need to specify when
> installing Apache::SessionX, I'm not sury whether I need any File stuff
> etc - I mean I know I'm going to use Postgres, but new users will
> probably need a bit more explanations in the README to help them decide
> what they really need.
I have tried to explain this in the text that Makefile.PL outputs, maybe you
have an idea how to write it better and could send me a patch :-)
>Upon second trial 'perl Makefile.PL' I just
> skipped everything and turned on just Postgres
It asks you if you want to change your already entered configuration. That's
so you don't have to enter the same things everytime you run Makefile.PL
> just to discover that I
> have to initialize DB the same way like plain Apache::Session - this is
> another thing I didn't understood at first from the README
>
Yes, the DB setup should be mentioned in the README, even better Makefile.PL
should try to create the database tables itself, or least verfiy that they
are exists, but that's out of my time possibilites at the moment, maybe
somebody else could pick that up...
> - after make test, all tests were succefull
>
> - when restarted, apache complains
>
> Starting httpd: Syntax error on line 205 of /etc/httpd/conf/httpd.conf:
> HTML::Embperl object version 1.3.3 does not match bootstrap parameter
> 1.3.4_dev at /usr/lib/perl5/5.6.0/i386-linux/DynaLoader.pm line 219.
> Compilation failed in require at (eval 8) line 3
>
> I changed the version number by hand and it worked
>
Runing Makefile.PL of Embperl would also had make this warning go away, but
this makes no difference.
> - I didn't exactly understood how the simplified configuration is
> supposed to work, but I tried to use %udat without any configuration and
> worked as I hoped... pretty cool
>
:-)
> - I played with %udat a bit and I didn't find any problem, %udat with PG
> works smoothly
>
> - my friend Honza reports the same result with his application, he
> promissed to post something to the list - if he doesn't get around it,
> brief summary is that it works great with his app using both %udat and
> %mdat, he played with it a bit more, with some four virtual servers and
> there were no errors. BTW he also reports that he played with Embperl
> 2b3 and he says its absofuckinglutely cool, showing over 30% speedup on
> even simple scripts and I understand Apache::SessionX works with it OK
>
> - I'm using mod_usertrack with Embperl sessions, I didn't find any
> problems
>
> Great work, Gerald, thanks. I'm so happy I'll probably install it on
> my production server in couple days ;-) Or should I wait for 1.3.4?
>
When you don't find any further problems, I think it's safe to install this
version. 1.3.4 will have some more new session stuff, but I am not sure when
it comes out.
Gerald
P.S. I send a copy of this mail to the list (also you mentioned that Honza
will send a separate mail), because more people have asked for Postgres
Session support and I guess they are interested in your positive results.
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Sessions with Postgres
Posted by Robert <ro...@robert.cz>.
Gerald Richter wrote:
>
> I think I will have a test version ready during next week and I send you a
> copy, so you can test it against Postgres in your environment.
Hi everybody,
I'm back at work (sort of) and I'm glad to see there's progress on the
Embperl/Session front. Gerald, when there's something you want us to
test in the CVS, would you post info to this list? I'm looking forward
too.
Related question: Can Embperl be safely downgraded? Can I install CVS
or 2.0beta version, test it and when something's wrong just reinstall
1.3.3 over it? Or should I delete stuff manually first? I did it couple
of times on my test server, but I got a little bit nervous about my
production server.
- Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Sessions with Postgres
Posted by Gerald Richter <ri...@ecos.de>.
>
> i get nervous about automatically committing on DESTROY.
>
That's reasonable
> I changed Store::Postgres to rollback if Transaction=>1 is given, and
> they did not explicitly call insert(), update() or remove() (which do
> a commit of their own).
>
> The "official" Store::Postgres doesn't use the Transaction option, so
> i hoped this wouldn't affect existing users.
>
>
> Theoretically, you could give neither Transaction nor Commit, and you
> would have an outstanding transaction, that you need to commit (or
> rollback) yourself (outside Apache::Session). as far as i could tell,
> this was the expected behaviour when Commit wasn't given. This, and
> not affecting existing users, was the reason i didn't just use "if
!Commit".
>
I would more like the "if !Commit" solution, because if you like
Apache::Session todo the commit for, then I would expect that it also does
the rollback, in case something went wrong.
>
> gerald, if the Apache::Session author has disappeared, i'm tempted to
> just take/fork it and start "fixing" it.
>
No, he isn't disapeared (his last post on the mod_perl list was yesterday),
he is simply very busy and so he isn't very responsible. Also he didn't like
the idea to build too much features into Apache::Session itself, he more
like the idea that other people derive from Apache::Session to implement
thier own features. That's the reason why I created HTML::Embperl::Session,
as a module that inherits from Apache::Session.
At the moment I started to convert HTML::Embperl::Session to
Apache::SessionX, which get extented features that I need for Embperl. I add
new features to have a better session handling in Embperl itself and
Apache::SessionX has the ability to overload the classes of Apache::Session
so we can quickly fix them. So I will build your rollback into
Apache::SessionX. Additionaly Apache::SessionX, will create a new storages
object (not the APache::SessionX object itself) for every request, so we are
sure all data is written, commited and unlock without the need of "close"
hack. As last point (for the first release), Apache::SessionX should make
configuration of Session much more easier (which is often a problem, as you
can see by the mails on the list)
I think I will have a test version ready during next week and I send you a
copy, so you can test it against Postgres in your environment.
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Sessions with Postgres
Posted by Angus Lees <gu...@switchonline.com.au>.
On Thu, Jul 12, 2001 at 07:24:11AM +0200, Gerald Richter wrote:
> I have one question about your Postgres patch:
>
> > 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)
> >
>
> Why do you need an extra 'rollback_on_destroy' ?
>
> Why can't you simply use commit ? (If we are allowed to commit, why
> shouldn't we rollback if anything went wrong?)
i get nervous about automatically committing on DESTROY.
I changed Store::Postgres to rollback if Transaction=>1 is given, and
they did not explicitly call insert(), update() or remove() (which do
a commit of their own).
The "official" Store::Postgres doesn't use the Transaction option, so
i hoped this wouldn't affect existing users.
Theoretically, you could give neither Transaction nor Commit, and you
would have an outstanding transaction, that you need to commit (or
rollback) yourself (outside Apache::Session). as far as i could tell,
this was the expected behaviour when Commit wasn't given. This, and
not affecting existing users, was the reason i didn't just use "if !Commit".
gerald, if the Apache::Session author has disappeared, i'm tempted to
just take/fork it and start "fixing" it.
--
- Gus
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Sessions with Postgres
Posted by Gerald Richter <ri...@ecos.de>.
Hi,
I just started to rework the session stuff, so things like Postgres should
(hopefully) work out of the box and to add some other nice features.
I have one question about your Postgres patch:
> 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)
>
Why do you need an extra 'rollback_on_destroy' ?
Why can't you simply use commit ? (If we are allowed to commit, why
shouldn't we rollback if anything went wrong?)
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Sessions with Postgres
Posted by Angus Lees <gu...@switchonline.com.au>.
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: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org