Re: Apache::DBI and DBD::Pg
On Sun, Jan 15, 2006 at 02:00:15AM +, Jeremy Nixon wrote: > Tyler MacDonald <[EMAIL PROTECTED]> wrote: > > > [Fri Jan 13 23:46:28 2006] [error] [client 192.168.99.112] DBD::Pg::db > > prepare_cached failed: FATAL: terminating connection due to administrator > > Here's the thing: if your database connection goes away, and Apache::DBI > opens a new one, any prepared statement handles you might have become > invalid, because prepared statements are per-connection. > > My way around it is to not use prepared statements. Another, better, way is to use prepare_cached() along with connect_cached(). http://search.cpan.org/src/TIMB/DBI_AdvancedTalk_2004/sld029.htm and later slides. Tim.
Re: Apache::DBI and DBD::Pg
Jeremy Nixon wrote: Here's the thing: if your database connection goes away, and Apache::DBI opens a new one, any prepared statement handles you might have become invalid, because prepared statements are per-connection. The prepare_cached() method he's using will check the statement handle and prepare it again on the new connection if necessary. My way around it is to not use prepared statements. The only cases I have where they would be of benefit would mean storing them across multiple requests, and with Apache::DBI, you can't do that. You can store them across multiple requests, with or without Apache::DBI. They can be useful within a single request, if you need to issue the same statement multiple times. - Perrin
Apache DBI
I installed Apache::DBI - 0.98 on FreeBSD 5.4 with mod_perl 1. Apache::DBI logs an entry in apache error log file every time it create(s) a new connection or using an existing connection to the database server. Is this normal with this version? And how do I turn that feature off? Cure
Apache::DBI
I installed Apache::DBI - 0.98 on FreeBSD 5.4 with mod_perl 1. Apache::DBI logs an entry in apache error log file every time it create(s) a new connection or using an existing connection to the database server. Is this normal with this version? And how do I turn that feature off? Example, 55933 Apache::DBI need ping: yes 55933 Apache::DBI already connected to 'database=database_name;host=info_here\AutoCommit=1^\PrintError=1^\Username=info_here' 55933 Apache::DBI need ping: yes 55933 Apache::DBI already connected to 'database=database_name;host=info_here\AutoCommit=1^\PrintError=1^\Username=info_here' The error log file will get huge after a while. Cure
Re: Apache::DBI and DBD::Pg
Perrin Harkins <[EMAIL PROTECTED]> wrote: > The prepare_cached() method he's using will check the statement handle > and prepare it again on the new connection if necessary. Not with Apache::DBI, though. The reconnect happens underneath DBI, and you end up with the same $dbh, which thinks the prepared statement is still valid. It looks like it would work perfectly with connect_cached, which I hadn't known about, but now that I do, I'm all excited to change my code to use it instead of Apache::DBI. -- Jeremy | [EMAIL PROTECTED]
Re: Apache::DBI and DBD::Pg
On Sun, 2006-01-15 at 23:11 +, Jeremy Nixon wrote:
> Perrin Harkins <[EMAIL PROTECTED]> wrote:
>
> > The prepare_cached() method he's using will check the statement handle
> > and prepare it again on the new connection if necessary.
>
> Not with Apache::DBI, though. The reconnect happens underneath DBI, and
> you end up with the same $dbh, which thinks the prepared statement is
> still valid.
Maybe I'm reading it incorrectly, but it looks like prepare_cached will
handle this. Look at this line from the sub:
my $cache = $dbh->FETCH('CachedKids');
That should return cached handles from the current $dbh, not an old one
that has been replaced. The statement handles are attached to the
database handle, so if it gets replaced, all the old ones go away.
This won't work if you cache them yourself, by putting them in globals
or something. That's why you should use prepare_cached instead of
caching statement handles on your own.
- Perrin
Re: Apache::DBI and DBD::Pg
Perrin Harkins <[EMAIL PROTECTED]> wrote:
> my $cache = $dbh->FETCH('CachedKids');
>
> That should return cached handles from the current $dbh, not an old one
> that has been replaced. The statement handles are attached to the
> database handle, so if it gets replaced, all the old ones go away.
Right, but Apache::DBI doesn't replace the database handle, it just
provides it with a new connection.
(I haven't looked at the DBI code, I'm just going on my experience, which
matches the original poster's.)
--
Jeremy | [EMAIL PROTECTED]
how to configure the mod_perl to show a jpeg file.
HI, All. I had configure the mod_perl environment, it is here: Alias /perl/ /home/ghw/myperl/webproject/ PerlSwitches -T AddHandler perl-script .pl SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI Order allow,deny Allow from all Ok, I will wirte a Perl source code, it can run very good. but if I put a jpeg format file int to dircitory : /home/ghw/myperl/webproject/, the error is occour. the log file record like that: [Mon Jan 16 09:54:06 2006] [error] Unrecognized character \\xFF at /home/ghw/myperl/webproject/12.jpg line 1.\n I guess the mod_perl think the jpeg file is perl source code, so it try run it. but it failed. and I will how to configure the file to mod_perl don't think the jpeg file is perl source code? Thanks Mike.G
Re: how to configure the mod_perl to show a jpeg file.
On Mon, 16 Jan 2006 10:37:24 +0800 黄叶 <[EMAIL PROTECTED]> wrote: > HI, All. > I had configure the mod_perl environment, it is here: > > Alias /perl/ /home/ghw/myperl/webproject/ > PerlSwitches -T > >AddHandler perl-script .pl >SetHandler perl-script >PerlResponseHandler ModPerl::Registry >PerlOptions +ParseHeaders >Options +ExecCGI >Order allow,deny >Allow from all > > > Ok, I will wirte a Perl source code, it can run very good. > but if I put a jpeg format file int to dircitory : > /home/ghw/myperl/webproject/, the error is occour. > > the log file record like that: > [Mon Jan 16 09:54:06 2006] [error] Unrecognized character \\xFF at > /home/ghw/myperl/webproject/12.jpg line 1.\n > > I guess the mod_perl think the jpeg file is perl source code, so it > try run it. but it failed. > > and I will how to configure the file to mod_perl don't think the jpeg > file is perl source code? You just need to put the JPEGs into another directory, when using ModPerl::Registry it assumes that everything in that directory is perl code. Also, you don't need this in there: AddHandler perl-script .pl - Frank Wiles <[EMAIL PROTECTED]> http://www.wiles.org -
Re: how to configure the mod_perl to show a jpeg file.
but, if i had a project, i want put the all thing a directory. Can i do like that? if I don't use the ModPerl::Registry or edit the ModPerl::Registry, that is correct? or there are the other way? thanks.
Re: Apache::DBI and DBD::Pg
On Sun, 2006-01-15 at 23:35 +, Jeremy Nixon wrote:
> Perrin Harkins <[EMAIL PROTECTED]> wrote:
>
> > my $cache = $dbh->FETCH('CachedKids');
> >
> > That should return cached handles from the current $dbh, not an old one
> > that has been replaced. The statement handles are attached to the
> > database handle, so if it gets replaced, all the old ones go away.
>
> Right, but Apache::DBI doesn't replace the database handle, it just
> provides it with a new connection.
No, it completely replaces the handle the Apache::DBI cache, so that you
get the new one instead of the dead one when you call DBI->connect().
Take a look at the (short and simple) Apache::DBI code. It's just a
hash of connections, and when one gets replaced, the old one is totally
gone.
If you have some code that is caching $dbh in a global or closure, and
not calling Apache::DBI->connect() on every request, it can't replace
that, and neither can DBI->connect_cached(). That defeats the auto-
reconnect features of both. I recommend not caching $dbh yourself,
except maybe in pnotes(), since pnotes() only last until the end of the
request.
- Perrin
Re: Apache::DBI and DBD::Pg
Perrin Harkins <[EMAIL PROTECTED]> wrote: > If you have some code that is caching $dbh in a global or closure, and > not calling Apache::DBI->connect() on every request, it can't replace > that, and neither can DBI->connect_cached(). That defeats the auto- > reconnect features of both. I recommend not caching $dbh yourself, > except maybe in pnotes(), since pnotes() only last until the end of the > request. Weird. I'm not caching across requests; I have a cleanup handler that calls rollback and disconnect, and then nukes my entire db wrapper from orbit. But I had the same trouble as the original poster when I tried using prepared statements. On the other hand, I have some funky code going on after trying to deal with DBI's handling of transactions -- I don't want AutoCommit, but it seems to be impossible to do "set transaction isolation level serializable" without it, because DBI won't open a transaction if you send that command, but won't let you send a "begin" yourself, and effectively won't let you call ->begin unless AutoCommit is on. So I do have more caching than I probably should, in order to keep state. That's where I'll start looking, then. -- Jeremy | [EMAIL PROTECTED]
