Perrin Harkins wrote:
>
> On Fri, 10 Nov 2000, Tim Sweetman wrote:
> > > 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 suspect automating via DBI would be a major pain, because you'd have
> > to be able to identify the "dangerous" changes in state. Probably
> > requiring SQL to be parsed. :(
>
> The current rollback cleanup doesn't parse SQL. It knows that a rollback
> won't do damage if there are no transactions to be cleaned up, so it's
> safe to do every time. If there are other things that work this way, you
> could add them. Probably wouldn't work for things like MySQL table locks
> though. People will have to do that themselves.
If the backend supports rollback, couldn't you just try that instead
of the ping method to see if you are still connected and get the
cleanup as a side effect?
> > In principle, you could probably have a ->do_not_reuse method which
> > could be called before someone does something dangerous. As long as they
> > remember.
>
> But that would also mean no more persistent connection. Maybe that would
> work if you don't do it very often.
It would be very useful to be able to specify at connect time that
you don't want a particular connection to be persistent. If you have
a lot of small databases or some with different user/password
permissions
you accumulate too many backend servers - but if you also have one
or more connections used all the time you don't want to give up
Apache::DBI. I'm not sure it is worth caching MySQL connections
on the same host, either since it is so fast to start up. Has
anyone timed the difference?
Les Mikesell
[EMAIL PROTECTED]
