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

Reply via email to