Subtle difference in object creation causes radically different object lifetime?

I'm running an app on Glassfish with the Sun JVM. One of our developers made a harmless-looking change that appears to have wreaked havoc with the system. All he did was to wrap an existing factory method call with another to provide some logging, like so:

// Old code
PreparedStatement stmt = connection.prepareStatement(sql);


// New code
PreparedStatement stmt = StatementLogger.prepareStatement(connection, sql);    

class StatementLogger {
    static PreparedStatement prepareStatement(Connection connection, String sql) {
        logger.info("Preparing SQL: " + sql);
        return connection.prepareStatement(sql);
    }
}

As a result of the change, it appears that the PreparedStatement has a much longer lifetime than it did previously. The statement is closed in exactly the same way in both cases. But with the change, we're running out of database connections.

Cer开发者_开发技巧tainly the live reference to the statement survives ever-so-slightly longer in the new version. That might give it a slightly better chance of surviving a minor garbage collection. But the difference appears trivial to me. (One frame pop.) Is there something else in the garbage collection that could let it identify the statement as a short-lived object in the first case but would identify it as long-lived in the second case?

What could be going on here?

---

The only effect on Garbage Collection of this change is that many new Strings are created, and then garbage collected.

when you say you run out of database connections, this has nothing to do with Objects processed by GC. You can still have a leak of Connection objects, but not run out of DB connections. You say you close the connection? Then you will not run out.

Oh and it might be that you are observing the problem now due to a load pattern change, not necessarily due to a code change.