On 5/4/18 12:16 PM, Shawn Heisey wrote: > On 5/4/2018 10:38 AM, Phil Steitz wrote: >> The only thing close to this that you can do now is if you have >> prepared statement pooling enabled, then via the JMX instrumentation >> of commons pool you can see the output of statement.toString(). >> See listAllObjects in GenericObjectPoolMXBean. Again, the pool you >> need to walk to get this is the prepared statement pool associated >> with an individual connection, not the connection pool. > Is this an answer to both parts of my query? Only the second part was > concerned with prepared statements. The first part was about getting > currently executing SQL queries from BasicDataSource.
The answer to that is no, you can't get it directly from any BDS method. > > I am not using prepared statements at this time. I will not be using > them anytime soon. The plan that includes prepared statements is a > complete rewrite of the application from scratch, to eliminate some > design problems. > > I was using PoolingDataSource in the past. Because setting that up > involves explicitly configuring the object pool, I did have access to > listAllObjects, but since switching to BasicDataSource (which appears to > be the recommended choice), that no longer seems to be available. You can access it via JMX, but what you will see is just the connection meta-data, what is exposed in PoolableConnectionMXBean. > > The "setAccessToUnderlyingConnectionAllowed" method implies that it > should be possible to access the connections ... but I can't figure out > how to do that. Even if I manage that, I haven't yet found a way to > descend from the connection to get the query. If you cast the connection returned by BDS as a DelegatingConnection and have setAccessToUnderlyingConnectionAllowed set to true, you can use the getInnermostDelegate method to get the underlying physical connection. In general, you are not going to be able to get to queries that way, though, as all you will have is the javax.sql.Connection methods. > > I acknowledge the possibility of an XY problem here, so here's what I'm > trying to do: > > When my application fires off an alarm email, I want that email to > include all SQL queries the application is executing at the moment of > the alarm. > > Because all DB access is coordinated through a single class (which I > creatively called "Database"), I can probably invent my own way of > tracking this info, but if I can do it through dbcp, that's one less > thing I have to write/debug. I don't think DBCP is going to be much help there. Another thing you might consider is setting up a database user ID for the app and using database utilities to dump the queries in progress for that user when your alarm triggers. Depending on the db / jdbc driver, you may be able to do this from within your Java app. See, e.g. [1] Phil [1] https://stackoverflow.com/questions/14036690/dynamic-output-for-show-processlist-in-mysql-using-java/14036759#14036759 > The alarm subroutines can only reach > things that have access to the datasource, not anything below that. > > I think the way I would do it myself is using a Map<Connection, String> > object built with Collections.synchronizedMap. When I close a > connection (return it to the pool), I can remove its entry from that > tracking map. > > Thanks, > Shawn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
