The code above will work for the simplest situation where the admin server also hosts the JDBC application we're tracing, but for the situation where the admin server is independent from the managed server(s) and several independent JVMs are involved we'll need to get the admin MBeans home instead of the local MBeans home. The difference between the two is that the local home provides the MBeans for a single server while the admin home provides MBeans for all of the servers, which are administered by an administration server. To get the admin MBeans home instead of the local MBeans home, replace LOCAL_JNDI_NAME with ADMIN_JNDI_NAME in the code above.

Step 3
It's useful if you provide a way to turn the JDBC profiling on and off because profiling is expensive and you should turn it off if you don't need it. The profiling is off by default so you'll have to turn it on before you can trace any JDBC statements. Create a method such as the following:

public void configureJDBCAuditing(boolean isOn) {
   try {
    MBeanHome home = getMBeanHome();
    //Retreive the bean to help us configure the Pool
JDBCConnectionPoolMBean mConfigBean =
(JDBCConnectionPoolMBean)home.getConfigurationMBean("MyPool","JDBCConnectionPoolConfig");
   mConfigBean.setSqlStmtProfilingEnabled(isOn);
   mConfigBean.setSqlStmtParamLoggingEnabled(isOn);
   } catch (InvalidAttributeValueException iave) {
   System.out.println("Invalid attribute while configuring tracing " + iave);
   } catch (InstanceNotFoundException infe) {
   System.out.println("Instance not found while configuring tracing " + infe);
   }
}

In the code above we are also telling the connection pool that we want to see the parameters going into the SQL statements. This adds to the overhead of the tracing but provides us with some valuable information.

Step 4
After we have configured the JDBC pool to store the profiles we can go ahead and ask for them. Remember that the number of profiles retrieved will be equal to the number of SQL statements executed since you turned the profiling on and not equal to all of the SQL statements that have ever been executed by the MyPool ConnectionPool. The code below retrieves the profiles; the parameter maxProfiles indicates how many of the most recent profiles should be fetched. Create a method such as:

/** Pass in -1 to get all profiles */
public JDBCStatementProfile[] getProfiles(int maxProfiles) {
   JDBCStatementProfile[] profiles = null;
   try {
    MBeanHome home = getMBeanHome();
JDBCConnectionPoolRuntimeMBean mbean =
(JDBCConnectionPoolRuntimeMBean)home.getRuntimeMBean("MyPool
","JDBCConnectionPoolRuntime");
    int numProfiles = mbean.getStatementProfileCount();
    int profilesIndex = 0;
    //figure out index to start at and how many we want
    if (maxProfiles != -1) {
    profilesIndex = numProfiles - maxProfiles;
}else {
    maxProfiles = numProfiles;
}
profiles =mbean.getStatementProfiles(profilesIndex,maxProfiles);
   } catch (InstanceNotFoundException infe) {
System.out.println("Problem retrieving jdbc profiles " + infe);
   }
   return profiles;
  }

The method getStatementProfiles of the JDBCConnectionPoolRuntimeMBean is missing from the WebLogic 8.1 API documentation, though it appears in the documentation for WebLogic 6.1. However, this appears to be a mistake since the method is available in 8.1 and a bug was fixed in this method in WebLogic 8.1 (CR094729 at http://e-docs.bea.com/wls/docs81/notes/resolved_sp01.html), which means that the method was meant to be included with WebLogic 8.1

Step 5
You can add a reset function so that you can clear the statement cache when you restart the server:

public void reset() {
   MBeanHome home = getMBeanHome();
   try {
JDBCConnectionPoolRuntimeMBean mbean =
(JDBCConnectionPoolRuntimeMBean)home.getRuntimeMBean("MyPool
","JDBCConnectionPoolRuntime");
//Remove everything from the cache
    mbean.resetStatementProfile();
   } catch (InstanceNotFoundException infe) {
System.out.println("Problem while resetting JDBC profiles " + infe);
   }
  }

Step 6
Iterate through the profiles to get the information you'd like to show (see Listing 1). This code would probably reside in the UI layer, such as in a JSP.

The Future of WebLogic JMX
WebLogic 9.0, which is a very recent release at the time of writing, supports JMX 1.2 instead of JMX 1.0, which was supported until WebLogic 8.1. In response to the change in the JMX specification, the WebLogic JMX API has changed quite a bit in 9.0 and the code in Listing 1 may generate deprecation warnings. When upgrading to 9.0 the JDBCDataSourceRuntimeMBean should replace the JDBCConnectionPoolRuntimeMBean. However, the vast majorities of legacy applications that are running on WebLogic are not using the 9.0 WebLogic Server at the time of writing, and probably will not do so for quite some time.