Re: [cgiapp] Teardown cleanup

["Mark Fuller" <suppressed>]

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


---------------------------------------------------------------------
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