At 01:26 PM 8/23/2001 -0700, Benjamin Trott wrote:
> > I haven't read the entire thread, so forgive me if I'm restating. But there
> > are reasons for sharing DB connections (and reasons not to). In the case of
> > MySQL and getting messages about active statement handles, that's because
> > you'r
From: Perrin Harkins <[EMAIL PROTECTED]>
> Database handles are never shared between processes. If you missed this,
> you should re-read the Apache::DBI docs.
Uh, oh. You're right, I spoke too quickly. And I did it more than once, sorry.
With separate processes, everything is new (mostly). In
>> Apache::DBI doesn't have a problem with transactions.
>
> Ah, OK. What about when a shared connection is rolled back in one process,
> will it effect other running processes with the same handle?
Database handles are never shared between processes. If you missed this,
you should re-read the A
From: Perrin Harkins <[EMAIL PROTECTED]>
> Apache::DBI doesn't have a problem with transactions.
Ah, OK. What about when a shared connection is rolled back in one process, will it
effect other running processes with the same handle?
---
Rodney Broom
Programmer: Desert.Net
>
>BT> By using the magic 6th arg ($connect_meth in the DBI::connect
>source) to
>BT> DBI::connect. In my DB wrapper I have a connect method that
>internally calls
>
>Duh... the source! What a concept ;-)
it's actually even documented (from DBI 1.18+ IIRC :)
The "dbi_connect_method" attribute c
On Thu, Aug 23, 2001 at 11:19:22AM -0700, Kyle Oppenheim wrote:
> 3. Apache::DBI intercepts the connect(), looks in it's hash and sees that it
> already has a connection. It pings the handle, fails, and deletes the entry
> from the hash. That's the last refcount on the dbh, so DESTROY gets call
> Nope, you've got it. If you don't have transactions (anything else?) to
worry about, I'd say to use
> Apache::DBI.
Apache::DBI doesn't have a problem with transactions. If you're doing
strange things like changing isolation levels on particular requests you can
get into trouble, but that's an
>>> PH> Don't open a connection during startup.
>>> PH> Open a connection in the child process instead.
>>
> BT > I will second this. I've done this (unintentionally) when using MySQL,
> and
> BT > you get a lot of weird errors about statement handles being active, etc.
>
> I haven't read the en
> "BT" == Benjamin Trott <[EMAIL PROTECTED]> writes:
>> that all clients also use? That is, how can I force Apache::DBI to
>> close that handle prior to the forking of children?
BT> By using the magic 6th arg ($connect_meth in the DBI::connect source) to
BT> DBI::connect. In my DB wrapper I
Rodney Broom <[EMAIL PROTECTED]> said something to this effect on 08/23/2001:
> From: Rasoul Hajikhani <[EMAIL PROTECTED]>
> > I am sorry but this topic is confusing me... Are you saying that
> > persistent DB connection objects are bad?
>
> It sounds like that, doesn't it?
This is only when one
From: Benjamin Trott <[EMAIL PROTECTED]>
> > PH> Don't open a connection during startup.
> > PH> Open a connection in the child process instead.
>
BT > I will second this. I've done this (unintentionally) when using MySQL, and
BT > you get a lot of weird errors about statement handles being act
Benjamin Trott wrote:
>
> > PH> Don't open a connection during startup. If you do, it will be shared when
> > PH> Apache forks, and sharing a database handle is bad for the same reasons
> > PH> sharig a file handle is. Open a connection in the child process instead.
>
> I will second this. I'v
> PH> Don't open a connection during startup. If you do, it will be shared when
> PH> Apache forks, and sharing a database handle is bad for the same reasons
> PH> sharig a file handle is. Open a connection in the child process instead.
I will second this. I've done this (unintentionally) when
We've seen this happen before. Unfortunately, I don't have a fix for you
but I here's where we left off our chase...
1. ORA-03113: end-of-file on communication channel (for unknown reason,
maybe a network blip?)
2. We have some code that will catch this error and call DBI->connect again.
3. Ap
[EMAIL PROTECTED] (Vivek Khera) wrote:
>> "PH" == Perrin Harkins <[EMAIL PROTECTED]> writes:
>PH> Don't open a connection during startup. If you do, it will be shared when
>PH> Apache forks, and sharing a database handle is bad for the same reasons
>PH> sharig a file handle is. Open a connec
> "PH" == Perrin Harkins <[EMAIL PROTECTED]> writes:
PH> Don't open a connection during startup. If you do, it will be shared when
PH> Apache forks, and sharing a database handle is bad for the same reasons
PH> sharig a file handle is. Open a connection in the child process instead.
Speaki
> On Wed, Aug 22, 2001 at 09:42:59AM -0400, Perrin Harkins wrote:
> > > > Are you using Apache::DBI? Are you opening a connection in
> the parent
> > > > process (in startup.pl or equivalent)?
> > > Yes, yes.
> >
> > Don't open a connection during startup. If you do, it will be
> shared when
> >
On Wed, Aug 22, 2001 at 09:42:59AM -0400, Perrin Harkins wrote:
> > > Are you using Apache::DBI? Are you opening a connection in the parent
> > > process (in startup.pl or equivalent)?
> > Yes, yes.
>
> Don't open a connection during startup. If you do, it will be shared when
> Apache forks, an
> > Are you using Apache::DBI? Are you opening a connection in the parent
> > process (in startup.pl or equivalent)?
> Yes, yes.
Don't open a connection during startup. If you do, it will be shared when
Apache forks, and sharing a database handle is bad for the same reasons
sharig a file handle
On Wed, Aug 22, 2001 at 09:07:59AM -0400, Perrin Harkins wrote:
> > (DBD: error possibly near <*> indicator at char 1 in '<*>select
> slogan_text
> > from
> > slogans') at /usr/local/www/lib/SQL.pm line 221.
> Are you using Apache::DBI? Are you opening a connection in the parent
> process (in st
> After some time of work (about hundred of requests), I get
>
> DBD::Oracle::db prepare failed: ORA-03113: end-of-file on communication
> channel
> (DBD: error possibly near <*> indicator at char 1 in '<*>select
slogan_text
> from
> slogans') at /usr/local/www/lib/SQL.pm line 221.
>
> and all Or
21 matches
Mail list logo
