MG>pls see below
________________________________
From: Shawn Heisey <[email protected]>
Sent: Friday, May 4, 2018 3:16 PM
To: [email protected]
Subject: Re: [DBCP] Possible to get query strings from datasource?
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.
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.
MG>have a chat with your DBA on BasicDataSource validationQuery
MG>if this was Oracle it would be something like select 1 from DUAL
MG>from an application perspective all you want is java.sql.Connection right?
MG>org.apache.commons.DelegatingStatement executes sql query parameter:
public ResultSet executeQuery(String sql) throws SQLException {
checkOpen();
try {
return
DelegatingResultSet.wrapResultSet(this,_stmt.executeQuery(sql));
}
catch (SQLException e) {
handleException(e);
throw new AssertionError();
}
}
MG>but who calls this ?
org.apache.commons.dbcp.PoolableConnectionFactory:
public void validateConnection(Connection conn) throws SQLException {
String query = _validationQuery;
if(conn.isClosed()) {
throw new SQLException("validateConnection: connection closed");
}
if(null != query) {
Statement stmt = null;
ResultSet rset = null;
try {
stmt = conn.createStatement();
if (_validationQueryTimeout > 0) {
stmt.setQueryTimeout(_validationQueryTimeout);
}
rset = stmt.executeQuery(query);
//where is validationQuery set?
// in the PoolableConnectionFactory constructor
public PoolableConnectionFactory(ConnectionFactory connFactory, ObjectPool
pool, KeyedObjectPoolFactory stmtPoolFactory, String validationQuery, boolean
defaultReadOnly, boolean defaultAutoCommit) {
//validationQuery is set in org.apache.commons.dbcp.BasicDataSource
public void setValidationQuery(String validationQuery) {
//so in the end whatever validationQuery YOU supply to BasicDataSource
//is the only sql query that you will see
MG>does this answer your question?
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.
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. 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: [email protected]
For additional commands, e-mail: [email protected]
