ConnectionPool responsibility is only to execute Validation Query and deliver connection from pre-assembled connection-pool
unfortunately since SQL queries come from implementor there is no way for lower level libraries such as commons-pool to know a-priori all of the queries being executed. Moreover look at all of the testcases you would need to test this TestForAllQueries TestForValidationQuery TestForOracle TestForPostgres TestForMySql TestforMongoDB? the same scenario would hold true if you wanted to trap username/password authentication creds since the database is the only entity to know the username/password credentials Threading is tricky business as you will need a ThreadMonitor to control and monitor your thread...something like this may help https://www.javatips.net/api/lightblue-migrator-master/migrator/src/main/java/com/redhat/lightblue/migrator/ThreadMonitor.java have you implemented a ThreadMonitor? Martin ______________________________________________ ________________________________ From: Shawn Heisey <apa...@elyograg.org> Sent: Friday, May 4, 2018 10:48 PM To: user@commons.apache.org Subject: Re: [DBCP] Possible to get query strings from datasource? On 5/4/2018 6:15 PM, Shawn Heisey wrote: > The implementation looks clean to me, but I need something bad to happen > before I will know if it's actually working. I added a background thread that periodically logs pool stats. At first, I never got it to line up with any actual database usage, and I never saw any queries in the stats. By fiddling with the exact timing for the first logging loop, I was able to get the pool stats to show me one of the the SQL queries that the program uses when it first starts up. Before I confirmed that, I did put a sanity check in to log all entries *removed* from the map, which showed me that queries were indeed being added. The second line of this log excerpt (and a whole bunch of other lines) shows an SQL query being removed: https://apaste.info/dJK0 (the QC abbreviation means "quietClose" ... the name of the method where I added the sanity-check logging.) Looks like I've got it doing what I want, and if any SQL queries are underway when an alarm is fired, they should be in the email. So I have a solution, and there should be enough information in this thread to help others do the same. I do wonder if similar SQL query tracking would be in-scope for DBCP datasource objects. Thanks, Shawn --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
