Peter Halliday wrote:
I can't find anything on how to set request data anymore. I really need
help. My set is down because of this.
Can you be more specific? What are you trying to do? What software are
you using? What were you doing before that stopped working? What did
you change?
-
I can't find anything on how to set request data anymore. I really need
help. My set is down because of this.
Peter Halliday
Excelsior Systems
http://www.excelsiorsystems.net
(Phone:) 607-936-2172
(Support:) 607-329-6905
(Fax:) 607-398-7928
Jonathan Vanasco wrote:
well yeah. its just a really weird situation that is easy to get into
and not really documented. i'm kind of surprised this didn't happen to
anyone else. maybe i'm just doing things REALLY wrong :)
Connecting with AutoCommit on and turning it off when you want to do
Jonathan Vanasco wrote:
Its a really peculiar thing - apache::dbi does the automatic rollback
at the end of scripts which is great for keeping things clean -- but if
you die for another reason and don't do a rollback, you can get that
implicit commit on the next request serviced by the child.
On Jan 13, 2006, at 10:17 PM, Perrin Harkins wrote:
This shouldn't be an issue in an Apache::DBI situation either, if
you didn't start out with AutoCommit = 1. When you have AutoCommit
turned off, it will do a rollback automatically at the end of every
request. You could manually push that
On Jan 13, 2006, at 10:06 PM, Philip M. Gollucci wrote:
I'll add this to my list of Apache-DBI things to look at ... but
that won't be for about 10 days or so
Thanks.
Have you looked at HandleError/RaiseError combo?
Yeah, I came across that after posting. That should do most of what
Jonathan Vanasco wrote:
This shouldn't be an issue in a non-ApacheDBI situation, because you'd
die on the RaiseError and never commit.
This shouldn't be an issue in an Apache::DBI situation either, if you
didn't start out with AutoCommit = 1. When you have AutoCommit turned
off, it will do a
Tyler MacDonald wrote:
[Fri Jan 13 23:46:28 2006] [error] [client 192.168.99.112] DBD::Pg::db
prepare_cached failed
Do you only have the problem with prepare_cached? Can you replicate it
in a small script that just connects and does the prepare_cached if you
restart the database?
- Perrin
Jonathan Vanasco wrote:
1 - Someone who understands this better than I - note this in the
Apache::DBI documentation. Probably in this paragraph:
I'll add this to my list of Apache-DBI things to look at ... but that
won't be for about 10 days or so
=current_pod
Transactions:
Bear with me, this is confusing to explain.
I noticed something on Apache::DBI (translated, i lost 2days figuring
out what was going on by trailing mysql query logs , and watching DBI
with a tracelevel )
I'm not sure what's causing this: apache:dbi or dbi , or even mysql
being stupid
th
Apache::DBI claims that it will reconnect to a database if it's gone away.
DBD::Pg claims that it supports the ping method. However, when I restart my
database server while apache2 is running, all mod_perl pages that are
database driven return internal server errors, no matter how many times I
refr
On Fri, 2006-01-13 at 12:11 -0500, [EMAIL PROTECTED] wrote:
> On database backend, I currently see 77 connections established.
> netstat on the front end indicates 77 active connections.
>
> However, Apache2::Status always displays 2 connection.
>
> Am I missing something?
That means you have tw
I am using Apache/mod_perl/ApacheDBI/DBI combination with connect_on_init()
to provide child processes (prefork model) with connections had had been
already established.
On database backend, I currently see 77 connections established.
netstat on the front end indicates 77 active connections.
How
13 matches
Mail list logo