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