M J wrote:
I’m very disappointed regarding the mod_perl 2 documentation and changes
that have been made.
I’m searching for several hours already how can I read the query params
using only mod_perl2 API.
I had problem installing libapreq2-2.06-dev and I’m tired to debug that
That's hard to say. I've been using mp2
professionally, and so far installing libapreq2 has been pretty painless; both
on Win32 and FreeBSD platforms. Win32 is pre-packaged, so it's quite
predictable. FreeBSD's version is compiled from source, but still it's
problem-free.
You really need t
Im very disappointed regarding the mod_perl 2 documentation and changes that have been made. Im searching for several hours already how can I read the query params using only mod_perl2 API. I had problem installing libapreq2-2.06-dev and Im tired to debug that library. I w
I took out the flags and the disconnect. I also set:
$Apache::DBI::DEBUG = 2;
to get debugging output.
I'm not getting any connection errors. (going to set mysql's max
connections to 150 per server)
What I'm seeing is 37 mysql threads being created for 7 apache
children. It would seem as
th
I took out the flags and the disconnect. I also set:
$Apache::DBI::DEBUG = 2;
to get debugging output.
I'm not getting any connection errors. (going to set mysql's max
connections to 150 per server)
What I'm seeing is 37 mysql threads being created for 7 apache
children. It would seem as
th
I'm using Apache/2.0.54 (Unix) mod_apreq2-20050712/2.1.3-dev mod_perl/2.0.1 Perl/v5.8.0
After a certain level of usage I get the following error:
failed: Too many connections at /usr/lib/perl5/5.8.0/Habitat/Apache2/DB.pm line 64\n,
When I do a server restart it's fine for a while. What do I ne
what DB are you using?
if you're using mysql, try opening a mysql client and doing a :
show processlist
it'll give you all the info on current connections
you can also turn on the querylog in the my.cnf file and have a
terminal tail -f it -- it'll show you all the process ids and wha
On Thursday 09 February 2006 19:14, Boysenberry Payne wrote:
> What are the ramifications of making AutoCommit => 0?
> It going to bite me in the but later?
I prefer to connect every connection with AutoCommit=>1. Then if I need a
transaction it is started with $dbh->begin_work and finished with
You're right it was a typo. Now that it's fixed it works using the do(
"USE database_name") syntax
with AutoCommit => 0
Thanks,
Boysenberry
boysenberrys.com | habitatlife.com | selfgnosis.com
On Feb 9, 2006, at 12:02 PM, Clinton Gormley wrote:
DBD::mysql::st execute failed: Table 'boy
Hi Boysenberry -
DBD::mysql::st execute failed: Table 'boysie_habtiat.sessions' doesn't exist
at /Users/boysie/mod_perl_inc/Habitat/DB/Select.pm line 95.
Shouldn't that be "boysie_habitat.sessions" ?
Larry
What are the ramifications of making AutoCommit => 0?
It going to bite me in the but later?
What are the pros and cons of using Apache::DBI::Cache over
Apache::DBI?
Thank for all of the help so far...
Boysenberry
boysenberrys.com | habitatlife.com | selfgnosis.com
On Feb 9, 2006, at 12:11 PM,
After reading up on Apache::DBI::Cache it seems like it might solve the
issues, thanks.
I'll reply again if it doesn't...
Boysenberry
boysenberrys.com | habitatlife.com | selfgnosis.com
On Feb 9, 2006, at 10:03 AM, Torsten Foertsch wrote:
On Thursday 09 February 2006 16:14, you wrote:
I wil
Ok I switched to using fully qualified database requests as:
database_name.table_name and received the following errors:
8854 Apache::DBI need ping: yes
8854 Apache::DBI new connect to 'database=adm_accounts;host=localhostNamePassAutoCommit=1PrintError=1RaiseError=1Usernam
What if you'd write all your SQL-Statements in a fully qualified manner?
---8<---
SELECT * FROM $DB1.$TABLE1;
SELECT * FROM $DB2.$TABLE1;
---8<---
Tom
Boysenberry Payne wrote:
> The only difference in each connection is the database. I tried conne
You could alter your SQL to use fully qualified table names, then you don't
need to execute the use statment.
ie.
SELECT whatever
FROM database.table
WHERE id = key
instead of
SELECT whatever
FROM table
WHERE id = key
This works in the version in mysql 4 and greater for sure, and quite poss
I got rid of the disconnect, duh. I still have the errors, but no longer get the
12844 Apache::DBI disconnect (overloaded)
Thanks,
Boysenberry
boysenberrys.com | habitatlife.com | selfgnosis.com
On Feb 9, 2006, at 9:14 AM, Boysenberry Payne wrote:
The only difference in each conne
The only difference in each connection is the database. I tried connecting
to the same database then using $h-do( "USE new_database" ); But it doesn't
switch to the new database (works fine using DBI.)
I decided as a temporary hack I'd try the following:
sub clean_processes {
my $self = shift;
I am using Apache::DB as debugger to debug my modperl2 program. No
breakpoints are defined, I input many 'r' and the return is always
like below, and the home page can't be displayed in the debug mode
while turning off debug mode it home page can be rendered as normal.
DB<1> r
void context retur
On Thursday 09 February 2006 07:35, Ken Perl wrote:
> I know Apache2:SizeLimit works ony with non-threaded MPMs, but I don't
> know how to fix the issue, any comments?
use apache with the prefork MPM. This is usually specified when you compile
your apache by passing '--with-mpm=prefork' to the co
the extra braces are just a way of keeping $sitetext_cache private to methods in the block.I haven't tried the other variations though - I will at some time. It seems to be flying happily with the use vars version though.
On 2/9/06, Perrin Harkins <[EMAIL PROTECTED]> wrote:
On Wed, 2006-02-08 at 21
20 matches
Mail list logo
