DB2 Driver Connection Hanging in Glassfish Connection Pool

Question

We have an intermittent issue around the DB2 used from a Glassfish connection pool. What happens is this:

Under situations where the database (DB2 on ZOS) is under stress, our application (which is a multi-threaded application using connections to DB2 via a Glassfish connection pool) stops doing anything.

The following are observed:

1) Looking at the server using JConsole, we can see a thread waiting indefinitely in the DB2 driver's getConnection() method. We can also see that it has gained a lock on a Vector within the driver. Several other threads are also calling the getConnection() method in the driver, and are hanging waiting for the lock on the Vector to be released.

2) Looking at the database itself, we can see that there are connections from the Glassfish server open and waiting to be used. It seems that there is some sort of mismatch between the connection pool on Glassfish and the connections actually open to DB2.

Has anyone come across this issue before? Or something similar? If you need any more information that I haven't provided, then please let me know!

Answer 1

Related perhaps: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4263113

are you on jdk1.5 ?

---

From a blog:

In Java 1.5 and earlier, all of the methods on java.sql.DriverManager are synchronized. Your initial call to DriverManager.getConnection(...) triggers the startup of HA-JDBC. As HA-JDBC initializes, it will eventually call DriverManager.getDriver(...) for each database url in your cluster. The calls to DriverManager.getDriver(...) occur in a different thread from your application thread, hence the deadlock.

There are at least 2 known workarounds for this problem:

• Upgrade to Java 1.6. After forever insisting that the blanket synchronization of java.sql.DriverManager was not a defect, Sun silently fixed this in Java 1.6.

• Rather than use DriverManager.getConnection(...) to obtain connections, use DriverManager.getDriver(...).connect(...) instead. This will circumvent the deadlock since DriverManager.getDriver(...) will not trigger HA-JDBC startup and Driver.connect(...) is not synchronized.