On Mon, 2005-12-05 at 17:51 +0100, Torsten Foertsch wrote:
> With Apache::DBI::Cache on the other hand handles are cached only when they
> are free.
Now I understand -- you are using the cache as a way to mark unused
handles. This is kind of confusing. It would be easier to understand
if you always kept them in the cache and just have a "in_use" attribute
that you set for each one or something similar. In fact you already
seem to have one with your "disconnected" attribute.
You actually could do all of this with a wrapper around Apache::DBI. It
could keep track of in-use handles and create new ones when needed by
adjusting a dummy attribute.
> There are 2 occasions when a handle can go out of use. Firstly,
> when C<disconnect> is called or when the handle is simply forgotten. The
> second event can be caught with a C<DESTROY> method.
DESTROY is unreliable. Scoping in Perl is extremely complicated and
modules like Apache::Session that rely on DESTROY for anything are a
source of constant problems on this list. People accidentally create
closures, accidentally return the object into a larger scope that keeps
it around longer, put it in global variables, etc. I would avoid this.
> Now you can have as much identical connections to a DB server as you need.
> For
> example you can connect 2 times with AutoCommit=>1 then start a transaction
> on one handle and use the second for lookups.
This sounds like a bad idea to me, since the second one won't be able to
see things added by the first one. There may be some other useful case
for this though.
> My module cannot provide C<all_handlers> since it does not know them all.
I think DBI will provide something equivalent soon.
The only serious issue I see with this module is the way you handle
rollbacks. This will only do a rollback if you call disconnect. What
happens if your code hits an unexpected error and dies without calling
disconnect? No rollback, and potentially a transaction left open with
questionable data and possibly locks. (You can't rely on the object
going out of scope for safety.) Apache::DBI prevents this with its
cleanup handler, although that is somewhat flawed as well if you connect
with AutoCommit on and then turn it off.
Hmm... It also does direct hash accesses on the $dbh object for storing
private data. That's a little scary. The $dbh->{AutoCommit} stuff in
DBI is special because it uses XS typeglob magic. Doing your own hash
accesses is not really safe.
- Perrin
