Re: [OT] Apache::DBI and Postgres
On Wed, May 14, 2003 at 10:48:45AM -0400, Eric Sammer wrote:
Not really a problem (yet), but out of curiousity...
I'm using Apache::DBI with postgres and while not serving requests, all
the postgres processes are listed as idle in transaction. Obviously,
the DBI connect statements are configured with AutoCommit = 0. It
doesn't seem to cause any real problems, but it does concern me that
postgres considers itself in a transaction with only a connect (i.e.
prior to a $dbh-prepare()). I threw some SELECTs at it and it's fine,
but I worry about transaction blocking under heavier load and with
INSERT, DELETE, and UPDATE statements. ...or maybe I'm just thinking too
Oracle-ish about it.
I noticed an interesting problem with regards to dates and times. If
you have columns that you let pgsql fill in, frex:
Column |Type | Modifiers
--+-+---
order_date | date| default date('now'::text)
order_time | time with time zone | default ('now'::text)::time(6) with time zone
Those dates and times will tend to be off, because pgsql uses the
exact date/time at the _start_ of the transaction. And with Apache::DBI
the transaction could have been started quite some time ago, unless your
server is heavily loaded and/or you do lots of SELECT queries before
adding new rows (thus making sure you end up with a relatively fresh
transaction).
Just to illustrate this, I first get the current time on my server:
dev= SELECT current_time;
timetz
20:11:20.787832-04
Then I go to my mod_perl application and add a new account. The
resulting row has:
order_date | order_time
+
2003-06-01 | 20:10:46.349862-04
And order_time in this row is chronologically before, even though I
added the account _after_ typing 'SELECT current_time' in my psql
console...
The date can be off too, if Apache::DBI used an old, stale transaction
that started the previous day (this is very possible if a new record is
added alightly after midnight...)
weird cookie behavior
I'm experiencing strange behavior with cookies when my scripts are
accessed in mod_perl (using Apache::Registry). Everything works fine so
long as my browser is configured to not go through a proxy (ie, in
Netscape 4.77, directly connected to the Internet option is selected).
When I configure it to use a custom proxy (eg, Junkbuster running on my
LAN gateway), my cookies no longer work, but I can still browse the web
fine.
I should point out that everything works ok when the scripts are
accessed as CGI's rather than mod_perl. Hence I'm fairly certain the
problem is not with the Junkbuster proxy, but has something to do with
mod_perl.
These are the software versions:
Debian/Linux 3.0
Apache 1.3.26 + mod_ssl 2.8.9 (running in proxy accelerator mode)
Apache 1.3.26 + mod_perl 1.26
Perl 5.6.1
I'm using CGI.pm to create the cookie headers. Typical code looks like this:
# Setting a cookie
# (the test.pl script will retrieve the cookie and check auth_info)
$cookie = MI_BakeCookie($q, $form-{'email'}, $form-{'passwd'});
print $q-redirect(-cookie=$cookie, -url=/perl/test.pl?op=menu);
# Retrieving a cookie
$cookie = $q-cookie('auth_info');
form{'email', 'crypt'} = split (':', $cookie);
# The function that creates the cookies...
# Creates a temporary auth_info cookie which contains the user's
# email address and encrypted password (MD5 hash).
sub MI_BakeCookie {
my ($q, $email, $password) = _;
my $crypt = md5_hex($password);
my $auth_info = join (':', $email, $crypt);
my $cookie = $q-cookie(-name='auth_info',
-value=$auth_info,
# -expires='+10d',
-path='/',
-secure=0 # haven't changed this yet...
);
return ($cookie);
}
It's all pretty straightforward stuff... which is why I'm confused and
hope that someone might have an idea as to what's going on here. I'm
open to any suggestions, but alas I don't have a lot of time to spare so
can't really afford to make my own custom handler and switch to
Apache::Cookie or whatnot. But if that's the only solution, then I
gotta do what I gotta do.
Anyway, please let me know if you have any ideas. :)
Re: Documentation for Apache::exit()?
On Tue, Sep 24, 2002 at 08:03:56PM -0700, Kyle Oppenheim wrote: There are a few performance penalties when using Apache::Registry: * Scripts are compiled at first request instead of server start unless you use something like Apache::RegistryLoader. So, the first request per child will be a little bit slower and you don't get to share memory between httpd children. (Memory sharing can be a big problem.) But it still shares all the modules you pre-load in the http.conf, right? So how much memory is wasted depends on the size of the script in question, or more accurately on how big its data structures are? (including imported variables) BTW, anyone know if Perl 6 will free unused memory? From what I understand, right now it just allocates as needed, but never gives any back to the OS when it's done... (ie, when some function ends)
Re: Apache::PerlRun weird behavior?
On Sun, Sep 01, 2002 at 12:58:18PM +0800, Stas Bekman wrote: Copy-n-pasted your conf and the code and I cannot reproduce the problem with Apache::PerlRun. Do you have this problem when you run the server under 'httpd -X'? Yes What mod_perl version are you using? Try to use the latest one. (though PerlRun didn't change for years). I've tested with: mod_perl 1.27 (perl 5.6.1 and 5.8.0) This was the environment: mod_perl 1.21, perl 5.005, apache 1.3.9 (all default packages that came with Debian 2.2r7) I finally had time to setup another machine with Debian 3.0 to test with, and it works like it's supposed to. Very strange... I have no idea what was causing the problem. The new software is: mod_perl 1.26, perl 5.6.1, apache 1.3.26 Note that probably none of these packages are standard, because Debian tends to patch a lot of software, so it's typically not 100% the same as if you download mod_perl from perl.apache.org and ran ./configure make make install... It makes it more difficult to tell what was causing the problem.
Apache::PerlRun weird behavior?
Hi I'm new at mod_perl, and I decided to start running my scripts with
Apache::PerlRun so I don't have to rewrite them right away (they're too
'dirty' to run under Apache::Registry). Anyway, I figured it was going
to be easy since PerlRun provides an environment similar to CGI, but
something strange is happening. There's a section in the User Guide that
talks about possible problems one can encounter with referenced
variables, so I figured I'd write a very simple test script to see if
that was the case with my code.
So the weird thing is that it runs fine the first time, but when I
reload the page, it doesn't show the variable I imported from
My::Config, and this is what the output looks like this:
html_dir =
count = 1
And this message shows up in the error.log:
[Sat Aug 31 19:59:15 2002] test.pl: Use of uninitialized value at
/home/val/www/cgi-bin/test.pl line 12.
This is such a simple script, but I can't figure out what I'm doing
wrong. What's even more weird is that if I change my httpd.conf to use
Apache::Registry instead of Apache::PerlRun, the script works fine!
(well the value of $count keeps incrementing, but I expected that).
Could someone please tell me what I'm doing wrong? My settings/code are
shown below:
- httpd.conf -
PerlWarn On
PerlTaintCheck On
PerlModule CGI
Alias /cgi-perl/ /home/val/www/cgi-bin/
Location /cgi-perl
SetHandler perl-script
PerlHandler Apache::PerlRun
Options +ExecCGI
allow from all
/Location
- test.pl -
#!/usr/bin/perl -w
use strict;
use CGI;
use My::Config;
use vars qw($count);
my $q = new CGI;
$count++;
print $q-header(-type='text/html');
print html_dir = $CF{'html_dir'}br;
print count = $countbr;
- My/Config.pm -
package My::Config;
use strict;
use Exporter;
use vars qw(ISA EXPORT %CF);
ISA = ('Exporter');
EXPORT = qw(%CF);
$CF{'html_dir'} = '/home/val/www/htdocs';
1;
