On Tue, Mar 20, 2018 at 21:21, Shawn Heisey <apa...@elyograg.org> wrote:
> Main Question: Does dbcp by chance record a stacktrace of the code that > requests a connection from the pool? I would like to poke my way > through the active connections (entry point being the DataSource > implementation), and ask them where in our code they were requested. Yes, that’s a flag you set in the data source. See for example BasicDataSource: abandoned usage tracking. I > have to do this in the Tomcat fork of dbcp, and I know I'm not on a > Tomcat mailing list, but I'm hoping that whatever you can tell me will > apply to that version too. If I can get a stacktrace of where each > connection was requested, I can pinpoint problematic code a lot faster. > There is a LOT of code that uses the database, scattered across a lot of > git repositories. If I could grep the code easily to find them all, I > would. IIRC, DBCP came from Tomcat in the first place. And they keep it synced upstream. > > Side question: Why has Tomcat maintained what looks like a fork of dbcp > for such a long time period? If they really believe their > implementation has an advantage, it seems like everyone would benefit if > they worked to get the upstream library to offer the same advantages. > Am I drifting into flamewar territory by even wondering about this? I > did find the tomcat documentation page about their connection pool. It > basically reads to me as "Commons DBCP is substandard and bloated. > These are the many ways that our implementation is better." > > https://tomcat.apache.org/tomcat-9.0-doc/jdbc-pool.html > > I haven't compared DBCP with other pool implementations, but my work > with DBCP has never run into any problems that weren't my own fault. > This mailing list has shown a high degree of patience with my dumb > questions. > > Thanks, > Shawn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > > -- Matt Sicker <boa...@gmail.com>
