Monday Jun 06, 2011

TOTD #164: JDBC Statement Leak Detection and Reclaim in GlassFish

If a JDBC Statement is not closed after use then the application will eventually run out of cursors. Enabling JDBC statement leak detection identifies such statements. These statements can be reclaimed as well, and cursors closed. Shalini blogged about how statement leakage can be detected and reclaimed. More details about this feature can also be found in Oracle GlassFish Server Online Docs.

This Tip Of The Day (TOTD) will show you can detect JDBC statement leakage and reclaim them using GlassFish 3.1.

  1. Edit the “glassfish/domains/domain1/config.xml” file and search for “jdbc-connection-pool” element with the name “DerbyPool”. Add the following attributes to the element:
    connection-leak-timeout-in-seconds="10" statement-timeout-in-seconds="6" 

    The attribute names are intuitive and specify the timeout options for JDBC statement and connection leakage. Notice, it follows the criteria of:
    statement-leak-timeout-in-seconds < statement-timeout-in-seconds < connection-leak-timeout-in-seconds
    Save the changes and (re)start the application server in NetBeans.
  2. Create a Java EE 6 project using NetBeans. Right-click on the project and select “New”, “Session Bean...”, select “Singleton” and specify the name as “TestBean”, a package name of “org.glassfish.samples” and click on “Finish”.
  3. Mark the bean for eager initialization by specifying the "@javax.ejb.Startup" at the class. This ensures that the bean is loaded during application deployment.
  4. Add the following method to the generated bean:
     void startup() {
       Connection c = null;
       Statement s = null;
       try {
         InitialContext ctx = new InitialContext();
         DataSource ds = (DataSource)ctx.lookup("jdbc/__default");
         c = ds.getConnection();
         s = c.createStatement();
       } catch (SQLException ex) {
       } catch (NamingException ex) {
       } finally {
         try {
           if (s != null)
           if (c != null)
         } catch (SQLException ex) {

    This is a working version of the code with JDBC connection and statements correctly closed.
  5. Deploy the project by right-clicking and selecting “Deploy”. Now comment the two lines in the “finally” block where the statement is checked for null and closed. The project gets autodeployed and the bean is initialized. The following message is displayed in the GlassFish logs in NetBeans:
    WARNING: A potential statement leak detected for connection pool DerbyPool. The
     stack trace of the thread is provided below :

    This ensures that JDBC statement leak detection is working. Notice the exact line where the statement is leaked is also highlighted in the stack trace.
  6. Now uncomment the lines previously commented and comment the lines where the connection is checked for null and closed. The following message is displayed in the GlassFish logs in NetBeans:
    WARNING: A potential connection leak detected for connection pool DerbyPool. The 
    stack trace of the thread is provided below : com.sun.enterprise.resource.pool.ConnectionPool.setResourceStateToBusy(

    This ensures that JDBC connection leak detection is working.
  7. Edit “glassfish/domains/domain1/config/domain.xml” and add the following attribute:

    to the “jdbc-connection-pool” element with the name “DerbyPool”. This will ensure that the leaked statement is reclaimed and the cursor is closed. Similarly adding


    ensures that the JDBC connection is reclaimed and returned to the pool.

Monday Feb 04, 2008

What's the big deal about GlassFish ?

users@glassfish had a discussion on what are the key differentiators of GlassFish. This blog summarizes them. Here is a list of distinguishing features:

  1. Fastest open source application server (883.66, highly scalable).
  2. Centralized management of clusters and instances distributed across multiple servers.
  3. Microsoft .NET 3.0 interoperability
  4. Java Business Integration and Open ESB
  5. Call flow analysis for diagnosing performance problems
  6. High performing  message queue implementation (Open Message Queue), with a highly available message store.
  7. SIP Servlet support and Telco Support via SailFin
  8. Very small footprint and flexibility via modularity in GlassFish v3.

And here is a list that makes the technical features all the more appealing:

  1. Out-of-the-box experience - Download to "sample app" in 10 minute
  2. Impressive monthly downloads - 430k for December 2007
  3. Good support on the forums.
  4. Update Center for downloading additional features, samples, blueprints, etc.
  5. Outstanding documentation
  6. Number of releases - Released GlassFish v1 in May 06, GlassFish v1 UR1, GlassFish v2 and GFv2 UR1. Now working on GlassFish v2.1 and GlassFish v3.
  7. Domain structure is nice, easy to upgrade the server and keep your configs in place.
  8. Packaging is nice and compact and does not expose underlying architecture. Specifically, you don't have to be an expert on Glassfish and how its built or designed to get good value out of it. The others are certainly powerful and flexible architectures, but they expose that complexity to you as a user, and it affects the learning curve.
  9. Gradual complexity. The admin gui, command line gui, the config files, the documentation make the simple stuff simple and the difficult stuff possible. Combined with Java EE 5, things mostly just work. Yet you have the depth of all of the configurations options to be able to take it where you want to go.

What is your favorite feature ?

Technorati: glassfish appserver performance

Thursday Nov 08, 2007

TOTD #16: Optimizing Metro Stubs by locally packaging the WSDL

When Metro stubs are used to invoke a Web service endpoint, two invocations are made over the network - one for retrieving the WSDL and the other for sending the request message.

The second invocation is easy to explain because that's when the actual message is sent to the endpoint.

The first invocation to retrieve the WSDL is necessary because the generated stubs contain only the portable method signatures and annotations. All the binding specific information, such as quality-of-service policy assertions, are retrieved at the runtime. This approach was taken because of two reasons:

  • All the binding information cannot be captured in the generated stubs
  • Quality-of-service may change between the stub generation and actual invocation.

However if the WSDL is not expected to change then you can consider locally packaging the WSDL with the client. In this case the locally packaged WSDL, instead of accessing over the network, is used to retrieve the binding information.

Metro runtime is integrated in GlassFish and can also be installed on Tomcat. Vivek explained the several Tooling options with Metro - NetBeans IDE being the most comprehensive.

Several screencasts are available to get you started with Metro.

Please leave suggestions on other TOTD that you'd like to see. A complete archive is available here.

Technorati: webservices metro glassfish netbeans performance totd


profile image
Arun Gupta is a technology enthusiast, a passionate runner, author, and a community guy who works for Oracle Corp.

Java EE 7 Samples

Stay Connected


« July 2016