Configuring and Managing WebLogic JDBC

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Monitoring WebLogic JDBC Resources

This release of WebLogic Server includes the WebLogic Diagnostic Framework, which is a monitoring and diagnostic service that runs within the WebLogic Server process and participates in the standard server life cycle. This service enables you to create, collect, analyze, archive, and access diagnostic data generated by a running server and the applications deployed within its containers. This data provides insight into the runtime performance of servers and applications and enables you to isolate and diagnose faults when they occur. WebLogic JDBC takes advantage of this service to provide enhanced runtime statistics, profile information over a period of time, logging, and debugging to help you keep your WebLogic domain running smoothly.

You can use the runtime statistics to monitor the data sources in your WebLogic domain to see if there is a problem. If there is a problem, you can use profiling to determine which application is the source of the problem. Once you’ve narrowed it down to the application, you can then use JDBC debugging features to find the problem within the application.

The following sections include details about monitoring JDBC objects:

For more information about the WebLogic Diagnostic Framework, see Configuring and Using the WebLogic Diagnostic Framework.

 


Viewing Runtime Statistics

Viewing runtime statistics allows you to monitor the data sources in your WebLogic domain.

Data Source Statistics

You can view runtime statistics for a data source via the Administration Console or through the JBCDataSourceRuntimeMBean. The JDBCDataSourceRuntimeMBean provides methods for getting the current state of the data source and for getting statistics about the data source, such as the average number of active connections, the current number of active connections, the highest number of active connections, and so forth. For more information, see JDBCDataSourceRuntimeMBean in the WebLogic Server MBean Reference.

Prepared Statement Cache Statistics

You can view runtime statistics for a prepared statement cache via the Administration Console or through the JBCDataSourceRuntimeMBean. For more information, see JDBCDataSourceRuntimeMBean in the WebLogic Server MBean Reference.

 


Collecting Profile Information

If the statistics that you are seeing indicate that there is a problem in your WebLogic Server domain, you can configure any data source to collect profile information to help you pinpoint the source of the problem. The collected profile information is stored in records in the WLDF Archive. The fields contain different information for different profile types, as described in the sections that follow.

When configuring your data source for profiling, you must specify the interval at which profile data is harvested (Harvest Frequency Seconds); if the interval is set to 0, harvesting of data is disabled. For more information, see Configuring the Harvester for Metric Collection.

Profile Types

You can choose to profile the following information about data sources and the prepared statement cache, as described in the next sections of this document:

Connection Usage (PROFILE_TYPE_CONN_USAGE_STR)

Enable connection usage profiling to collect information about threads currently using connections from the pool of connections in the data source. This profile information can help determine why applications are unable to get connections from the data source.

Note: By default, enabling connection usage profiling on its own will not provide a stack trace of the threads using the connections. To obtain this information you must enable profiling of connection leaks in addition to enabling connection. For more information about profiling connection leaks see Connection Leak (PROFILE_TYPE_CONN_LEAK_STR).

The record contains the following information:

Connection Reservation Wait (PROFILE_TYPE_CONN_RESV_WAIT_STR)

Enable connection reservation wait profiling to collect information about threads currently waiting to reserve a connection from the data source. This profile information can help determine why applications are unable to get connections from the data source or to wait for connections. The record contains the following information:

Connection Reservation Failed (PROFILE_TYPE_CONN_RESV_FAIL_STR)

Enable connection reservation failure profiling to collect information about threads that attempt to reserve a connection from the data source but fail to get that connection. This profile information can help determine why applications are unable to get connections from the data source even after reserving them. The record contains the following information:

Connection Leak (PROFILE_TYPE_CONN_LEAK_STR)

Enable connection leak profiling to collect information about threads that have reserved a connection from the data source and the connection leaked (was not properly returned to the pool of connections). This profile information can help determine which applications are not properly closing JDBC connections. The record contains the following information:

Connection Last Usage (PROFILE_TYPE_CONN_LAST_USAGE_STR)

Enable connection last usage profiling to collect information about the previous thread that last used the connection. This information is useful when you are debugging problems with connections infected in pending transactions that cause subsequent XA operations on the connections to fail. The record contains the following information:

Connection Multithreaded Usage (PROFILE_TYPE_CONN_MT_USAGE_STR)

Enable connection multithreaded usage profiling to collect information about threads that erroneously use a connection that was previously obtained by a different thread. This information is useful when an application reports a problem that you suspect may have been caused by the simultaneous use of a connection by more than one thread. The record contains the following information:

Statement Cache Entry (PROFILE_TYPE_STMT_CACHE_ENTRY_STR)

Enable statement cache entry profiling to collect information for prepared and callable statements added to the statement cache, and for the threads that originated the cached statements. This information can help you determine how the cache is being used. The record contains the following information:

Statements Usage (PROFILE_TYPE_STMT_USAGE_STR)

Enable statements usage profiling to collect information about threads currently executing SQL statements from the statement cache. This information can help you determine how statements are being used. The record contains the following information:

Accessing Diagnostic Data

Once profile data has been collected, you can access it using code similar to that shown in the sample below, substituting the appropriate profile type for the one shown in boldface type. The first part of the code defines a vector variable (dataV) in which the collected profile data (jdbcProfData) is stored. The second part of the code gets the stored data from the vector variable and prints it.

}
jdbcProfData = getData("EventsDataArchive", "TYPE LIKE '%" +
JDBCLegalHelper.PROFILE_TYPE_CONN_USAGE_STR + "%'");
Vector dataV = new Vector();
for (int i = 0; i < jdbcProfData.length; i++) {
if (jdbcProfData[i].getPoolName().equalsIgnoreCase
(Data_Source_1))
dataV.add(jdbcProfData[i]);
}

System.out.println("records found for PROFILE_TYPE_CONN_USAGE_STR : " +
dataV.size());
for (int a = 0; a < dataV.size(); a++) {
System.out.println("ID : " + ((ProfileDataRecord)
dataV.get(a)).getId());
System.out.println("PoolName : " + ((ProfileDataRecord)
dataV.get(a)).getPoolName());
System.out.println("Time : " + ((ProfileDataRecord)
dataV.get(a)).getTimestamp());
System.out.println("User : " + ((ProfileDataRecord)
dataV.get(a)).getUser());
}

Another method for accessing diagnostic data is to use the Data Accessor component of the WebLogic Diagnostic Framework (WLDF); for more information see “Accessing Diagnostic Data With the Data Accessor” in Configuring and Using the WebLogic Diagnostic Framework.

Callbacks for Monitoring Driver-Level Statistics

WebLogic Server provides callbacks for methods called on a JDBC driver. You can use these callbacks to monitor and profile JDBC driver usage, including methods being executed, any exceptions thrown, and the time spent executing driver methods.

To enable the callback feature, you specify the fully qualified path of the callback handler for the driver-interceptor element in the JDBC data source descriptor (module). Your callback handler must implement the weblogic.jdbc.extensions.DriverInterceptor interface. When you enable JDBC driver callbacks, WebLogic Server calls the preInvokeCallback(), postInvokeExceptionCallback(), and postInvokeCallback() methods of the registered callback handler before and after invoking any method inside the JDBC driver.

Any time an application calls the JDBC driver, a callback is sent to the class that implemented the driver.

 


Debugging JDBC Data Sources

Once you have narrowed the problem down to a specific application, you can activate WebLogic Server’s debugging features to track down the specific problem within the application.

Enabling Debugging

You can enable debugging by setting the appropriate ServerDebug configuration attribute to "true." Optionally, you can also set the server StdoutSeverity to "Debug".

You can modify the configuration attribute in any of the following ways.

Enable Debugging Using the Command Line

Set the appropriate properties on the command line. For example,

-Dweblogic.debug.DebugJDBCSQL=true 
-Dweblogic.log.StdoutSeverity="Debug"

This method is static and can only be used at server startup.

Enable Debugging Using the WebLogic Server Administration Console

Use the WebLogic Server Administration Console to set the debugging values:

  1. If you have not already done so, in the Change Center of the Administration Console, click Lock & Edit (see Using the Change Center).
  2. In the left pane of the console, expand Environment and select Servers.
  3. On the Summary of Servers page, click the server on which you want to enable or disable debugging to open the settings page for that server.
  4. Click Debug.
  5. Expand default.
  6. Select the check box for the debug scopes or attributes you want to modify.
  7. Select Enable to enable (or Disable to disable) the debug scopes or attributes you have checked.
  8. To activate these changes, in the Change Center of the Administration Console, click Activate Changes.
    Not all changes take effect immediately—some require a restart (see Using the Change Center).
  9. This method is dynamic and can be used to enable debugging while the server is running.

Enable Debugging Using the WebLogic Scripting Tool

Use the WebLogic Scripting Tool (WLST) to set the debugging values. For example, the following command runs a program for setting debugging values called debug.py:

java weblogic.WLST debug.py

The debug.py program contains the following code:

user='user1'
password='password'
url='t3://localhost:7001'
connect(user, password, url)
edit()
cd('Servers/myserver/ServerDebug/myserver')
startEdit()
set('DebugJDBCSQL','true')
save()
activate()

Note that you can also use WLST from Java. The following example shows a Java file used to set debugging values:

import weblogic.management.scripting.utils.WLSTInterpreter;
import java.io.*;
import weblogic.jndi.Environment;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;

public class test {
public static void main(String args[]) {
try {
WLSTInterpreter interpreter = null;
String user="user1";
String pass="pw12ab";
String url ="t3://localhost:7001";
Environment env = new Environment();
env.setProviderUrl(url);
env.setSecurityPrincipal(user);
env.setSecurityCredentials(pass);
Context ctx = env.getInitialContext();

interpreter = new WLSTInterpreter();
interpreter.exec
("connect('"+user+"','"+pass+"','"+url+"')");
interpreter.exec("edit()");
interpreter.exec("startEdit()");
interpreter.exec
("cd('Servers/myserver/ServerDebug/myserver')");
interpreter.exec("set('DebugJDBCSQL','true')");
interpreter.exec("save()");
interpreter.exec("activate()");

} catch (Exception e) {
System.out.println("Exception "+e);
}
}
}

Using the WLST is a dynamic method and can be used to enable debugging while the server is running.

Changes to the config.xml File

Changes in debugging characteristics, through console, or WLST, or command line are persisted in the config.xml file. See Figure 6-1, Example Debugging Stanza for JDBC, on page 6-10:

Listing 6-1 Example Debugging Stanza for JDBC
.
.
.
<server>
<name>myserver</name>
<server-debug>
<debug-scope>
<name>weblogic.transaction</name>
<enabled>true</enabled>
</debug-scope>
<debug-jdbcsql>true</debug-jdbcsql>
</server-debug>
</server>
.
.
.

This sample config.xml fragment shows a transaction debug scope (set of debug attributes) and a single JDBC attribute.

JDBC Debugging Scopes

It is possible to see the tree view of the DebugScope definitions using java weblogic.diagnostics.debug.DebugScopeViewer.

You can enable the following registered debugging scopes for JDBC:

Request Dyeing

Another option for debugging is to trace the flow of an individual (typically “dyed”) application request through the JDBC subsystem. For more information, see “Configuring the Dye Vector via the DyeInjection Monitor” in Configuring and Using the WebLogic Diagnostic Framework.


  Back to Top       Previous  Next