RE: [cgiapp] Teardown cleanup

["Kinyon, Rob" <suppressed>]

Mark -

	I'll address your concerns in order.

1) The primary benefit of packages is another namespace. What this means
is that you can have function foo() in your script and function foo() in
your package. As long as your package isn't called 'main', you have a
unique name for each foo(). This means you don't have to know what's
going on under the hood in the package to make sure you don't
accidentally clobber a name it's depending on.

The secondary benefit is that packages are how Perl5 does OO. But,
that's irrelevant to some people.

Under mod_perl, putting it into a package allows you to load the code
prior to the Apache server forking. This means that the time to serve a
given request is shorter and the memory needed per child process is
smaller, because the code has already been loaded and is being shared
with each child. So, the more code you can load pre-fork, the faster
each process will run and the more processes you can have running at the
same time. I've seen some statistics where taking a bunch of require'd
code and converting it to packages allowed for a 50%+ improvement in
response time and the ability to have 2-3x as many simultaneous requests
handled.

2) Most of the rest of your statements, in my opinion, fall under the
"premature optimization" category. Have you benchmarked Apache::DBI to
determine if it's too slow? Note that I didn't say "slower", but "too
slow". If your method takes 1ms and Apache::DBI takes 2ms, it's obvious
yours is faster. But, it's also obvious (to me) that the difference is
completely irrelevant. And, since your method requires more of your
developer time, Apache::DBI looks (to me) to be the overall win.

Remember - hardware is faster than software. Hardware capability
improves expontentially and software capability increases linearly.
Developer time is now the most expensive portion of a piece of software.
Minimizing the amount of time you have to spend working on a piece of
software is the quickest way to minimize the cost of that software.

Additionally, you minimize your risk. The number of bugs in your
software increases with the number of lines you write. If you could
replace a chunk of your code with a chunk that's been battle-tested in
thousands of other places, wouldn't that be better? In my opinion, I
would prefer to take a minor execution hit that my users will never be
aware of to reduce the overall complexity of what I personally have to
maintain.

Now, if you wanted to contribute your design back to the maintainers of
Apache::DBI, that would be a strong benefit to the community as a whole.
You get the benefit of using proven software and we get the benefit of
an improved design. And, if the design is not better than what's in
Apache::DBI, you not only learn why, but you *still* get the benefit of
proven software.

Thanks,
Rob

P.S. - have you even read the source for Apache::DBI? You mention having
read articles, but there's nothing like reading the source to understand
something.

-----Original Message-----
From: Mark Fuller [mailto:suppressed 
Sent: Sunday, June 27, 2004 7:55 PM
To: Thilo Planz; suppressed
Cc: suppressed
Subject: Re: [cgiapp] Teardown cleanup

From: "Thilo Planz" <suppressed>
>
>So what I usually do here is make packages

That makes sense. I put my database stuff in "db.pl" and require it. So,
what's the advantage of putting it in db.pm as a package. I've never
quite
understood why packages are preferred. To me, it seems like requiring a
.pl
library and calling subroutings passing parameters by reference (to be
modified in the subroutine) would be more efficient than what I *think*
is
happening in packaged modules. So far I've not noticed any negatives
using
.pl libraries.

From: suppressed
>
>under mod_perl if you use Apache::DBI then it will transparently cache
your
database connections

I read on Perl Monks (maybe where my questions belonged) there are some
downsides to Apache::DBI. I read in another article that Apache::DBI
pings
the database connection prior to each use. And, And it checks for a
cached
prepared-statement before each use.

I came up with my own connection manager which assumes the connection is
up
and the statement is prepared. In other words, it goes into connect mode
and
prepare mode only after a failed database operation (executed within an
eval). I thought this kind of exception processing would be more
efficient
than (if I understood correctly) Apache::DBI's treating all access as
exceptional (looking for an already used statement handle, pinging the
connection).

My dbh_handler subroutine is called *only after* a failed access. My
statement handles are in a hash. A "db_active" boolean helps me know,
after
a failure, whether I expect dbh to be connected or not. It's basic
logic:

1. If not db_active, connect and prepare the sth_hash{name} that just
failed.
2. If db_active, and sth_hash{name} is undefined, prepare it.
3. Otherwise, it was a real failure. Call a subroutine to disconnect
from
the database, set db_active to false, undef everything in %sth_hash (in
preparation for the next retry to start fresh).

My code performs SQL in a while (!some_subroutine()) loop. It will retry
the
SQL some configurable number of times. "Some_subroutine" executes $sth->
within an eval. If $@ (result of the eval), it calls the dbh_handler
passing
it (by reference) the dbh, sth_hash, statement name and a coderef to the
prepare subroutine.

It works ok for me. It puts all the DB handling after an error. It
otherwise
expects everything to work well and doesn't do any testing prior to
executing database stuff. I can share examples if anyone wants it. It's
just
an sth prepare subroutine (for each statement handle). A select (or
insert,
update, whatever) subroutine for each sth. And, the dbh_handler error
subroutine which handles 3 possible conditions.

Mark 
  
CONFIDENTIALITY NOTICE: The information in this electronic transmission and any documents accompanying it may contain confidential information belonging to the sender, which is legally privileged.  The information is intended only for the use of the individual or entities named above.  If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this information is strictly prohibited.  If you have received this transmission in error, please destroy the message in its entirety. 

---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed