You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Sean T Allen <se...@usaherbals.com> on 2005/01/04 20:18:36 UTC
mp2 and Class:DBI
I looked to see and couldnt find any reports of issues with
using Class::DBI w/ mod-perl 2 but wanted to check here to
see if there are any I should be aware of...
Also, if anyone could give me a basic ballpark on how much
I could expect to see per process memory usage jump
by using Class::DBI, I'd appreciate it.
Thanks in advance...
Re: mp2 and Class:DBI
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Wed, 5 Jan 2005, Stas Bekman wrote:
>
>
>>Mike Carlton wrote:
>>[...]
>>
>>>But isn't there a problem with making db connections from startup.pl?
>>>When the processes later fork, you potentially wind up with database
>>>connection problems (I saw lots of problems under MP1 when I was doing
>>>this).
>>>
>>>Particularly with Class::DBI::mysql, just loading a class makes a
>>>database connection. Is there a safe way to make database connections
>>>from startup.pl and not have it blow up?
>>
>>Not if you use PerlChildInitHandler to open the actual connection, like
>>Apache::DBI does:
>>http://modperlbook.org/html/ch20_02.html
>
>
> Hi Stas,
> It's probably just me, but just to clarify the wording -
> are you saying the use of PerlChildInitHandler, as in
> Apache::DBI, *is* a safe way to to initiate database
> connections within a startup.pl?
Yes, because it does *not* initializes the connection at startup. It
simply registers a handler that will be run at child_init. So each child
process will have its own connection.
> Also, does that depend on
> whether one's using threads (assuming the underlying
> database engine is thread safe). Thanks.
Frankly, I'm not sure what happens under threads. Apache::DBI doesn't
implement CLONE, so it might be a problem.
FWIW, I'm planning to restart my work on DBI::Pool soon and then I'll know
to tell more.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mp2 and Class:DBI
Posted by Perrin Harkins <pe...@elem.com>.
On Wed, 2005-01-05 at 14:58 -0600, Randy Kobes wrote:
> It's probably just me, but just to clarify the wording -
> are you saying the use of PerlChildInitHandler, as in
> Apache::DBI, *is* a safe way to to initiate database
> connections within a startup.pl?
It is, since it doesn't actually open any connections, but rather
postpones that until after the fork. That's what connect_on_init()
does.
> Also, does that depend on
> whether one's using threads (assuming the underlying
> database engine is thread safe).
It's only safe if it runs after the threads are spawned. Not sure if
this is the case or not.
- Perrin
Re: mp2 and Class:DBI
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Wed, 5 Jan 2005, Stas Bekman wrote:
> Mike Carlton wrote:
> [...]
> > But isn't there a problem with making db connections from startup.pl?
> > When the processes later fork, you potentially wind up with database
> > connection problems (I saw lots of problems under MP1 when I was doing
> > this).
> >
> > Particularly with Class::DBI::mysql, just loading a class makes a
> > database connection. Is there a safe way to make database connections
> > from startup.pl and not have it blow up?
>
> Not if you use PerlChildInitHandler to open the actual connection, like
> Apache::DBI does:
> http://modperlbook.org/html/ch20_02.html
Hi Stas,
It's probably just me, but just to clarify the wording -
are you saying the use of PerlChildInitHandler, as in
Apache::DBI, *is* a safe way to to initiate database
connections within a startup.pl? Also, does that depend on
whether one's using threads (assuming the underlying
database engine is thread safe). Thanks.
--
best regards,
randy
Re: mp2 and Class:DBI
Posted by Stas Bekman <st...@stason.org>.
Mike Carlton wrote:
[...]
> But isn't there a problem with making db connections from startup.pl?
> When the processes later fork, you potentially wind up with database
> connection problems (I saw lots of problems under MP1 when I was doing
> this).
>
> Particularly with Class::DBI::mysql, just loading a class makes a
> database connection. Is there a safe way to make database connections
> from startup.pl and not have it blow up?
Not if you use PerlChildInitHandler to open the actual connection, like
Apache::DBI does:
http://modperlbook.org/html/ch20_02.html
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mp2 and Class:DBI
Posted by Perrin Harkins <pe...@elem.com>.
On Tue, 2005-01-04 at 21:42 -0800, Mike Carlton wrote:
> But isn't there a problem with making db connections from startup.pl?
Only if you don't close them before forking.
> Particularly with Class::DBI::mysql, just loading a class makes a
> database connection.
Right, but Class::DBI doesn't do this, so it's not an issue if you
aren't using the fancy auto-discovery stuff in the subclasses.
> Is there a safe way to make database connections
> from startup.pl and not have it blow up?
Call MyClass->db_Main->disconnect() at the end of it.
- Perrin
Re: mp2 and Class:DBI
Posted by Mike Carlton <mi...@gmail.com>.
On Tue, 04 Jan 2005 15:47:50 -0500, Perrin Harkins <pe...@elem.com> wrote:
> On Tue, 2005-01-04 at 14:18 -0500, Sean T Allen wrote:
> > I looked to see and couldnt find any reports of issues with
> > using Class::DBI w/ mod-perl 2 but wanted to check here to
> > see if there are any I should be aware of...
>
> Class::DBI currently breaks the transaction-safety feature of
> Apache::DBI. This is not an issue if you are using MySQL without
> transactions. See this message for more:
> http://mathforum.org/epigone/modperl/teuthocrix/1098821949.2903.49.camel@localhost.localdomain
>
> > Also, if anyone could give me a basic ballpark on how much
> > I could expect to see per process memory usage jump
> > by using Class::DBI, I'd appreciate it.
>
> I can't give you a ballpark, but you should expect some jump. The
> amount really depends on how you use it. If you load large sets of data
> as Class::DBI objects, it will be significantly larger than doing the
> same thing with basic DBI results. If you only work with small sets
> loaded at once, your main increase will just be form additional modules
> being loaded. Load your Class::DBI stuff in startup.pl to minimize the
> unshared memory.
>
> - Perrin
>
>
But isn't there a problem with making db connections from startup.pl?
When the processes later fork, you potentially wind up with database
connection problems (I saw lots of problems under MP1 when I was doing
this).
Particularly with Class::DBI::mysql, just loading a class makes a
database connection. Is there a safe way to make database connections
from startup.pl and not have it blow up?
--mike
Re: mp2 and Class:DBI
Posted by Perrin Harkins <pe...@elem.com>.
On Tue, 2005-01-04 at 14:18 -0500, Sean T Allen wrote:
> I looked to see and couldnt find any reports of issues with
> using Class::DBI w/ mod-perl 2 but wanted to check here to
> see if there are any I should be aware of...
Class::DBI currently breaks the transaction-safety feature of
Apache::DBI. This is not an issue if you are using MySQL without
transactions. See this message for more:
http://mathforum.org/epigone/modperl/teuthocrix/1098821949.2903.49.camel@localhost.localdomain
> Also, if anyone could give me a basic ballpark on how much
> I could expect to see per process memory usage jump
> by using Class::DBI, I'd appreciate it.
I can't give you a ballpark, but you should expect some jump. The
amount really depends on how you use it. If you load large sets of data
as Class::DBI objects, it will be significantly larger than doing the
same thing with basic DBI results. If you only work with small sets
loaded at once, your main increase will just be form additional modules
being loaded. Load your Class::DBI stuff in startup.pl to minimize the
unshared memory.
- Perrin