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:
currentNumConnectionsOpenmaxConnectionsOpennumGetCallsaverageGetTimemaxGetTimenumCloseCallsaverageCloseTimemaxCloseTimeaverageOpenTimemaxOpenTime
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. IflogDebugStacktraceis 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. IflogDebugStacktraceis alsotruethen 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.
