Hi, sorry for the late answer.
I'll try to explain what Apache::DBI and my module does. Maybe it will then be clear why my module cannot be compatible with Apache::DBI and why it therefore must be an extra module. In fact I thought at first to create a quick patch to Apache::DBI. It would have saved a lot of work. With Apache::DBI when DBI->connect is called the first time for a given DSN an attributes a new DBI handle is created and stored in %Connected. When DBI->connect is called a second time with the same parameters Apache::DBI finds a matching handle in %Connected and reuses it. Additionally, at request cleanup time Apache::DBI checks all handles created with AutoCommit=>0 and rolls a possibly pending transaction back. From this logic there can only be one handle for a given set of attributes (and DSN). And this makes sense for Apache::DBI because there is no notion whether a handle is really in use or not. Further, Apache::DBI provides a C<all_handlers> subroutine that allows code outside Apache::DBI to access %Connected and thus to all cached handles. With Apache::DBI::Cache on the other hand handles are cached only when they are free. When DBI->connect is called the module tries to find a matching free one in the cache. If that fails a new one is created. Then the handle is returned to the caller and Apache::DBI::Cache do NOT hold any references to the handle. 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. Apache::DBI::Cache catches these 2 events and puts the handle in the cache preventing it from really get disconnected. In the DESTROY case it adds a reference and the handle will not be touched by the garbage collector. 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. When the lookup fails (missing table, missing column etc.) it does not disturb your transaction. Of course by adding a dummy attribute this could also be achieved with Apache::DBI. But suppose a big installation with quite a number of independent developers. Dummy attributes can be quite error-prone. Further, maybe you want to do something even a transaction over the lifetime of a connection. This cannot be done with Apache::DBI. (I don't say that would be good practice.) My module cannot provide C<all_handlers> since it does not know them all. Torsten On Sunday 04 December 2005 10:45, Enrico Sorcinelli wrote: > On Wed, 30 Nov 2005 13:37:56 -0500 > > Perrin Harkins <[EMAIL PROTECTED]> wrote: > > Hi Torsten, > > > > A few comments on the new module: > > > While Apache::DBI caches connections at connect time this module caches > > > them only at disconnect or DESTROY. > > > > Why? I don't understand the value in doing this. > > > > > Apache::DBI does not distinguish between currently used and free > > > connections. Hence, it cannot support multiple identical connections. > > > This module does. > > > > To get multiple connections to the same database with Apache::DBI, you > > just need to add something unique to the attributes hash in your connect > > string. > > > > > Apache::DBI resets all connections at request cleanup. > > > Apache::DBI::Cache intercepts disconnect or DESTROY events to do that. > > > > For the rollback you mean? That's not good. The purpose of the > > automatic rollback in Apache::DBI is to reset the connection when your > > code dies due to a bug. There won't be any disconnect or DESTROY called > > in that situation. > > > > > Apache::DBI::Cache includes the DBD driver name in the caching key > > > while Apache::DBI does not. Hence with Apache::DBI the following 2 DSNs > > > can result in the same DBI handle: dbi:mysql:dbname=db and > > > dbi:Pg:dbname=db > > > > Sounds like a good idea. > > > > > I wrote this module because Apache::DBI had changed the logic of our > > > programs. > > > > How so? > > > > > Further, we had really much DSNs mostly MySQL in various configuration > > > files all using different syntaxes to connect to a dozen databases on 2 > > > database hosts. > > > > I think the normalization of connect strings is a good idea. It could > > be useful on its own, for people who don't use mod_perl. > > > > - Perrin > > Hi Torsten, > > as Perrin says, your module has some nice things and some that I don't > understand too much me too. > > Apache::DBI is a well known and famous module largely used by mod_perl > users. IMHO, trying to improve that instead of writing a new one would have > been the better thing for the mod_perl community. > > Have you contacted Apache::DBI maintainer in order to integrate your work > with that module? > > by > > - Enrico
