On Mar 20, 2006, at 5:48 PM, Perrin Harkins wrote:
Here's my guess -- are you calling you DBI->connect() on every
request?
yep.
If this is all making you annoyed with Apache::DBI, just make your own
cleanup handler that does a rollback. It's easy to do, as long as you
have a simple way to g
On Mon, 2006-03-20 at 17:29 -0500, Jonathan Vanasco wrote:
> I'm not even seeing an explicit rollback on the good handle, which
> makes me think something odd happened on my config
Here's my guess -- are you calling you DBI->connect() on every request?
If you don't, Apache::DBI won't work. I'v
On Mar 20, 2006, at 3:50 PM, Perrin Harkins wrote:
It only does that if you connect with AutoCommit off.
my connect args are
{ RaiseError => 0, AutoCommit => 0 , TraceLevel => 1 }
Can you give an example of an invalid SQL command, and what was "bad"
about the cached handle on the nex
On Mon, 2006-03-20 at 15:22 -0500, Jonathan Vanasco wrote:
> I did a bunch of tracing this morning it seems that apache::dbi isn't
> always issuing the rollback at cleanup
It only does that if you connect with AutoCommit off.
> if there's an invalid sql command executed in my transaction though
a) i fixed the 'message ' errors - they were indeed from an
accidentally preforked handle. i'll try to make a note or something
for apache docs this evening.
b)
I did a bunch of tracing this morning it seems that apache::dbi isn't
always issuing the rollback at cleanup
I set a trace
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> c- i was getting a bunch of "message type 0x49 arrived from server
> while idle" -> "message type 0x53 arrived from server while idle"
This is due to some errant forking. PostgreSQL (and most other databases
for that matter) does not support
I'm finishing up my migration to Postgres, and i noticed some odd
behavior
I was hoping that someone could point me in the right direction:
a - i often lose a connection to the server for an apache child. i
can't seem to trace when where or why this happens
i just get this in the log "DBD
