On Thu, 9 Nov 2000, Tim Sweetman wrote:
> Apache::DBI is, as far as I know, dangerous, and people rarely seem to
> warn of this.
It's no more dangerous than any other scheme for persistent connections,
like JDBC pooling, etc.
> It's dangerous because:
> (a) Although it rolls back any transactions automatically, it may not
> deal with other persistant
> state on the handle. (Does it clear MySQL table locks, for
> instance?). Other settings, such
> as the lock timeout (SQL: "SET LOCK MODE TO WAIT nnn") or isolation
> levels, will also persist.
Would you be interested in adding support for resetting some of these to
Apache::DBI? It's pretty easy to do, using PerlCleanupHandler like the
auto-rollback does. It would be database-specific though, so you'd have
to find a way for people to explicitly request cleanups.
I used to do something like this to call finish() on all of my cached
statement handles, back when prepare_cached() used to die on unfinished
handles. (Now it just warns.)
> (b) Presumably, what were previously separate transactions on the same
> database on different handles
> can become entangled:
>
> TX1: BEGIN WORK
> TX2: BEGIN WORK
> TX1: INSERT A
> TX2: COMMIT
> TX1: INSERT B
>
> ... this would probably cause either fatal errors, or very strange
> things to happen.
Wouldn't this be the same with Apache::DBI or without it? Or are you
saying that this would have been done with two separate database
connections before Apache::DBI came into the mix? You can still get
multiple connections through Apache::DBI if you really want to. Just vary
anything at all in the connect string ({MyBogusParam => 1}) and you'll get
a different handle.
> (b) could be trapped by Apache::DBI refusing to give out two copies of
> the same DBH at the same
So you would check handles in and out? I suppose that would work, but it
sounds like a lot of trouble to handle a very unusual case to me. I don't
think I've ever seen an application that used multiple unrelated
transactions on the same database with interleaved operations like this.
It looks like something that would be more likely to happen in a threaded
environment where database handles were shared across threads.
- Perrin
