This section describes the use of the WatcherDataSource
class to debug data source problems. This feature is automatically available for all application servers.
Using Datasource Debugging
The default JTDataSource
allows you to monitor and log data source information for debugging purposes. It does this using the WatcherDataSource
class. A WatcherDataSource
“wraps” another data source, allowing debugging of the wrapped data source. For example:
/atg/dynamo/service/jdbc/JTDataSource.properties
$class=atg.service.jdbc.WatcherDataSource
# The actual underlying DataSource.
dataSource=/atg/dynamo/service/jdbc/DirectJTDataSource
Note: Due to the potential performance impact, the features described here should be used only for debugging in a development environment. Do not use datasource logging in a production environment unless absolutely necessary.
To view all logged data from the WatcherDataSource
, go to /atg/dynamo/service/jdbc/JTDataSource
in the Dynamo Component Browser.
WatcherDataSource Configuration
The default WatcherDataSource
configuration is:
showOpenConnectionsInAdmin=false
logDebugStacktrace=false
loggingDebug=false
monitored=false
loggingSQLError=true
loggingSQLWarning=false
loggingSQLInfo=false
loggingSQLDebug=false
This default configuration logs the following information:
currentNumConnectionsOpen
maxConnectionsOpen
numGetCalls
averageGetTime
maxGetTime
numCloseCalls
averageCloseTime
maxCloseTime
averageOpenTime
maxOpenTime
For additional debugging information, you can set the following properties to true
:
showOpenConnectionsInAdmin
—Lists currently open connections, along with the amount of time they have been held open and the thread that is holding them open. This information is useful for identifying Connection leaks. IflogDebugStacktrace
is also true, then stack traces are displayed as well.Note: This momentarily prevents connections from being obtained or returned from the DataSource, and severely affects performance.
loggingDebug
—Logs debug messages on everygetConnection()
andclose()
call. These messages include interesting information such as sub-call time, number of open connections, and the calling thread. IflogDebugStacktrace
is alsotrue
then a stack trace is logged as well.logDebugStacktrace
—Creates stack traces on eachgetConnection()
call. This allows the calling code to be easily identified, which can be useful when trying to find Connection leaks, code that is holding Connections open for too long, or code that is grabbing too many Connections at a time.Note: This is done by generating an exception, which affects performance.
monitored
—Gathers additional connection statistics and SQL logging.