Tim wrote:
> Now I want to do things "right" and am trying to understand
> Apache::DBI. Before looking at the module I imagined that it would
> work by providing a library of persistent connections. You would
> check a connnection out of the library, use it, and then put it back
> when you are done, like checking a book out of the library. If you
> disconnected the connection, you just wouldn't return it, and the
> pool would have to create a new connection for the next user.
Hrrmm. In this case though how would you discern between a
slow connection and a 'disconnect' on the clients side ?!
As far as we are aware, you couldnt, unless you sent back
some sort of message to the server in which case it may as
well deal with the disconnection itself at that point.
(jst our opinion ;)
> But this is not the way Apache::DBI works. Instead, if I understand
> correctly after glancing at the module this morning, two consecutive
> identical connect calls will return the same connection! Why isn't
> this a problem? Is the assumption that two different transactions
> will use different user/pwd combinations?
Afaik (or afaict) apache::dbi seems to cache any connection by
l&p (login and passwd) and server host/dbname. This is fine for
us here because everyone has a unique l&p to the database
anywayz. If you only use one for l&p for all connections, then
it doesnt really matter 'who has the handle' as long as its open
for business surely ?!
The dbi handle (in other words) doesnt block whilst in a cgi,
which you seem to think it is doing. It _will_ (if i read this right)
if you have a large select or fetchrow call, but otherwise the
concurrency shouldnt really be a problem (its all a matter how
of how quick/slow your queries are).
personally, in our application here, the individuals do a lot
of large transactions, and even though DBI might queue them
up, it would cause unacceptable delays in processing time.
of course, there are other things to worry about if everyone has
a unique l&p and more than once we have seen people advocating
against this.
your mileage may vary.
> Thanks
np (if i am right ;)
^stefs^
